1*1 


IJglerxsj  m&HUCh  9m  HscHenshe  ?r  iJflirfSijpf  emeni 
Ouvcioprienl  Curjd;i  In  riukirsL1  Canadi 


Helicopter  Maritime  Environment  Trainer: 
Software  Product  Specification 


Edited  by: 

Leo  Boutette 
Ken  Ueno 

Jason  Dielschneider 


This  manual  represents  the  operation  of  the  HelMET  System  as  originally  installed  with  hardware 
updates  to  the  current  date.  For  current  system  start-up  procedures  consult  the  Helicopter  Maritime 
Environment  Trainer  (HelMET)  Start-Up,  Virtual  Lesson  Plan  (VLP)  Editor  &  Shutdown  Manual 
Application  Version  4.0.  For  current  Operational  Procedures  consult  the  Helmet  4  4  IOS  User's  Guide 
Rev  Oil 


Defence  R&D  Canada 

Technical  Memorandum 
DRDC  Toronto  TM  201 1-050 
June  201 1 


Canada 


Helicopter  Maritime  Environment  Trainer: 
Software  Product  Specification 


Edited  by: 

Leo  Boutette 
Ken  Ueno 

Jason  Dielschneider 


Defence  R&D  Canada  -  Toronto 

Technical  Memorandum 
DRDC  Toronto  TM  2011-050 
June  201 1 


This  manual  represents  the  operation  of  the  HelMET  System  as  originally  installed  with  hardware  updates 
to  the  current  date.  For  current  system  start-up  procedures  consult  the  Helicopter  Maritime  Environment 
Trainer  (HelMET)  Start-Up,  Virtual  Lesson  Plan  (VLP)  Editor  &  Shutdown  Manual  Application  Version 
4.0.  For  current  Operational  Procedures  consult  the  Helmet  4  4  10S  User's  Guide  Rev  Ol  1. 


Principal  Author 


Original  signed  by  See  Original  Document.  Edited  by:  Leo  Boutette;  Ken  Ueno;  Jason 

Dielschneider 

See  Original  Document.  Edited  by:  Leo  Boutette;  Ken  Ueno;  Jason  Dielschneider 
Human  Effectiveness  Exploitation  Centre 

Approved  by 

Original  signed  by  David  Eaton 
David  Eaton 

Section  Head,  Human  Effectiveness  Exploitation  Centre 

Approved  for  release  by 

Original  signed  by  Dr.  Stergios  Stergiopolous 
Dr.  Stergios  Stergiopolous 

Acting  Chair,  Knowledge  and  Information  Management  Committee 

Acting  Chief  Scientist 


This  document  is  a  revision  of  DRDC  Toronto  Document:  CR2002-030  Atlantis  Document: 
AP905-03128  titled  Helicopter  Maritime  Environment  Trainer:  Software  Product  Specification 
with  updates  to  Version  4.4  of  the  HelMET  software. 


©  Her  Majesty  the  Queen  in  Right  of  Canada,  as  represented  by  the  Minister  of  National  Defence,  2011 


©  Sa  Majeste  la  Reine  (en  droit  du  Canada),  telle  que  representee  par  le  ministre  de  la  Defense  nationale, 
2011 


Abstract 


The  Helicopter  Maritime  Environment  Trainer  (HelMET)  was  developed  by  Defence  R&D 
Canada  -  Toronto  (DRDC  Toronto)  for  training  helicopter  pilots  to  land  on  the  flight  deck  of  a 
Canadian  Patrol  Frigate  (CPF)  in  a  virtual  environment.  The  HelMET  was  installed  at  12  Wing, 
Canadian  Forces  Base  (CFB)  Shearwater,  Nova  Scotia,  Canada  [reference:  Summary  per 
document  cited  in  next  paragraph]. 

DRDC  Toronto  Document:  CR2002-030  Atlantis  Document:  AP905-03128  titled  Helicopter 
Maritime  Environment  Trainer:  Software  Product  Specification  documented  Version  1.1  of  the 
HelMET  Software. 

As  third  party  support  for  the  HelMET  system  did  not  come  to  fruition,  DRDC  Toronto  has  been 
supporting  the  HelMET  system  at  12th  Wing  Shearwater  with  hardware  and  software  updates.  The 
current  version  of  HelMET  is  Version  4.4.  Many  of  the  updates  implemented  were  made  to  allow 
the  simulator  to  be  used  as  a  procedures  trainer. 

This  document  is  a  revision  of  CR2002-030  updated  to  reflect  the  large  number  of  changes  that 
have  been  implemented  by  DRDC  Toronto  since  version  1.1.  The  purpose  of  this  document  is  to 
update  the  description  so  that  the  system  can  be  maintained  and  operated  by  Director  Aerospace 
Development  Program  Management,  Radar  and  Communications  Systems  or  its  representatives. 


Resume 


Le  Simulateur  d’entrainement  virtuel  pour  helicoptere  maritime  (HelMET)  a  ete  developpe  par 
Recherche  et  developpement  pour  la  defense  Canada  -  Toronto  (RDDC  Toronto)  afm  d’entrainer 
les  pilotes  d’helicoptere  a  l’atterrissage  sur  le  pont  d’envol  d’une  fregate  canadienne  de  patrouille 
dans  un  environnement  virtuel.  Le  systeme  HelMET  a  ete  installe  a  la  12e  Escadre,  Base  des 
Forces  canadiennes  Shearwater,  Nouvelle-Ecosse,  Canada  [reference  :  sommaire  par  document 
cite  dans  le  paragraphe  suivant]. 

Document  RDDC  Toronto  :  CR2002-030,  document  Atlantis  :  AP905-03128  intitule  Simulateur 
d’entrainement  virtuel  pour  helicoptere  maritime  :  Specification  de  produit  logiciel, 
documentation  de  la  version  1 . 1  du  logiciel  HelMET. 

Etant  donne  que  la  prise  en  charge  du  systeme  HelMET  par  un  tiers  ne  s’est  pas  realisee,  c’est 
RDDC  Toronto  qui  en  assure,  par  consequent,  le  soutien  a  la  12e  Escadre  Shearwater  au  moyen 
de  mises  a  niveau  de  materiel  et  de  mises  a  jour  de  logiciel.  La  demiere  version  du  logiciel 
HelMET  est  la  version  4.4.  De  nombreuses  fonctionnalites  qui  ont  ete  implementees  visaient  a 
permettre  au  simulateur  d’etre  utilise  comme  systeme  d’entrainement  aux  procedures. 
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Le  present  document  est  une  revision  du  document  CR2002-030  dont  la  mise  a  jour  vise  a  refleter 
le  grand  nombre  de  modifications  apportees  au  logiciel  par  RDDC  Toronto  depuis  la  version  1.1. 
L’objectif  de  ce  document  est  de  rnettre  a  jour  les  descriptions  de  fagon  a  ce  que  le  systeme  puisse 
etre  maintenu  et  utilise  par  le  Directeur  -  Gestion  du  programme  de  developpement  aerospatial 
(systeme  de  radar  et  de  communication)  ou  ses  representants. 
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Executive  summary 


Helicopter  Maritime  Environment  Trainer:  Software  Product 
Specification: 

Leo  Boutette;  DRDC  Toronto  TM  2011-050;  Defence  R&D  Canada  -  Toronto; 
June  2011. 

The  Helicopter  Maritime  Environment  Trainer  (HelMET)  was  developed  by  Defence  R&D 
Canada  -  Toronto  (DRDC  Toronto)  for  training  helicopter  pilots  to  land  on  the  flight  deck  of  a 
Canadian  Patrol  Frigate  (CPF)  in  a  virtual  environment.  The  HelMET  was  installed  at  12  Wing, 
Canadian  Forces  Base  (CFB)  Shearwater,  Nova  Scotia,  Canada  [reference  Summary  per 
document  cited  in  next  paragraph]. 

DRDC  Toronto  Document:  CR2002-030  Atlantis  Document:  AP905-03128  titled  Helicopter 
Maritime  Environment  Trainer:  Software  Product  Specification  documented  Version  1.1  of  the 
HelMET  Software. 

As  third  party  support  for  the  HelMET  system  did  not  come  to  fruition,  DRDC  Toronto  has  been 
supporting  the  HelMET  system  at  12th  Wing  Shearwater  with  hardware  and  software  updates.  The 
current  version  of  HelMET  is  Version  4.4.  Many  of  the  updates  implemented  were  made  to  allow 
the  simulator  to  be  used  as  a  procedures  trainer. 

This  document  is  a  revision  of  CR2002-030  updated  to  reflect  the  large  number  of  changes  that 
have  been  implemented  by  DRDC  Toronto  since  version  1.1.  The  purpose  of  this  document  is  to 
update  the  description  so  that  the  system  can  be  maintained  and  operated  by  Director  Aerospace 
Development  Program  Management,  Radar  and  Communications  Systems  or  its  representatives. 
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Forces  canadiennes  Shearwater,  Nouvelle-Ecosse,  Canada  [reference  :  sommaire  par  document 
cite  dans  le  paragraphe  suivant]. 

Document  RDDC  Toronto  :  CR2002-030,  document  Atlantis  :  AP905-03128  intitule  Simulateur 
d’entrainement  virtuel  pour  helicoptere  maritime  :  Specification  de  produit  logiciel, 
documentation  de  la  version  1 . 1  du  logiciel  HelMET. 

Etant  donne  que  la  prise  en  charge  du  systeme  HelMET  par  un  tiers  ne  s’est  pas  realisee,  c’est 
RDDC  Toronto  qui  en  assure,  par  consequent,  le  soutien  a  la  12e  Escadre  Shearwater  au  moyen 
de  mises  a  niveau  de  materiel  et  de  mises  a  jour  de  logiciel.  La  demiere  version  du  logiciel 
HelMET  est  la  version  4.4.  De  nombreuses  fonctionnalites  qui  ont  ete  implementees  visaient  a 
permettre  au  simulateur  d’etre  utilise  comnie  systeme  d’entrainement  aux  procedures. 


Le  present  document  est  une  revision  du  document  CR2002-030  dont  la  mise  a  jour  vise  a  refleter 
le  grand  nombre  de  modifications  apportees  au  logiciel  par  RDDC  Toronto  depuis  la  version  1.1. 
L’objectif  de  ce  document  est  de  mettre  a  jour  les  descriptions  de  fagon  a  ce  que  le  systeme  puisse 
etre  maintenu  et  utilise  par  le  Directeur  -  Gestion  du  programme  de  developpement  aerospatial 
(systeme  de  radar  et  de  communication)  ou  ses  representants. 
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1  Scope 


1.1  Identification 

This  Software  Product  Specification  (SPS),  DRDC  Toronto’s  Document  Number  CR2002-030, 
identifies  and  records  the  inventory  of  software  contents  and  installation  instructions  required  to 
build  the  HelMET  Operational  Software  Computer  Software  Configuration  Item  (CSC1).  This 
SPS  also  provides  information  needed  for  future  software  maintenance  and  updates  of  the 
HelMET. 

1.2  System  Description 

1.2.1  Simulator  General  Description 

The  HelMET  CSC1  is  a  training  software  that  runs  on  the  HelMET  developed  by  the  Defence 
R&D  Canada  -  Toronto  (DRDC  Toronto)  for  training  helicopter  pilots  to  land  on  the  flight  deck 
of  a  Canadian  Patrol  Frigate  (CPF)  in  a  virtual  environment. 

The  Sea  King  HelMET,  herein  referred  to  as  the  simulator,  Helicopter  Deck  Landing  Simulator 
(HDLS),  Virtual  Reconfigurable  Simulator  (VR-Sim),  or  Reconfigurable  Helicopter  Simulator 
(RHS),  is  designed  to  provide  comprehensive  initial  training  and  refresher  courses  in  a  virtual 
environment  for  pilots  of  Sea  King  helicopters  in  landing  on  a  flight  deck  of  a  CPF.  Use  of  the 
simulator  provides  for  effective  training  and  evaluation  while  minimizing  the  high  cost  of 
operating  ship  and  aircraft  for  training  missions  and  eliminating  the  inherent  danger  of  personnel 
injury  and/or  damage  of  aircraft  and  ship. 

The  HelMET  was  installed  at  12  Wing,  Canadian  Forces  Base  (CEB)  Shearwater,  Nova  Scotia, 
Canada. 

The  simulator  consists  of  the  following  major  areas  as  illustrated  in  Figure  1. 

•Administration  Station 
•Low  Frequency  Station 
•Instructor  Operator  Station  (10S) 

•Trainee  Pilot  Station 

•Second  Pilot  Station 

•Landing  Signals  Officer  (LSO)  Station 

•Equipment  Rack  Station2 

•Motion  Platform  Power  Station 

•Equipment  Rack  Station  1 

•Medium  Frequency  Station 

•Audio  Communication  Subsystem  Station 

The  Administration  Station  provides  the  computing  facilities  for  simulations  and  controls. 
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The  Low  Frequency  Station  houses  two  low  frequency  loud  speakers. 

The  Instructor  Operator  Station  provides  the  instructor  operator  with  the  necessary  controls  and 
displays  to  effectively  control,  monitor,  communicate  and  evaluate  a  helicopter  deck  landing 
training  exercise. 

The  Trainee  Pilot  Station  provides  a  crew  station  for  the  pilot  to  be  trained  in  a  virtual 
environment.  The  station  is  equipped  with  a  head-mounted  display  (LIMD)  with  headset,  pilot 
seat,  cyclic  pitch  stick,  collective  pitch  lever  and  tail  rotor  pedals  housed  on  an  electric  motion 
base. 

The  Second  Pilot  Station  provides  a  crew  station  for  the  pilot  to  assist  in  training  a  trainee  pilot  in 
a  virtual  environment.  The  station  is  equipped  with  a  head-mounted  display  (HMD)  with  headset, 
pilot  seat,  and  controls  for  the  landing  gear. 

The  Landing  Signals  Officer  (LSO)  Station  provides  a  crew  station  for  an  operator  to  act  as  the 
LSO  while  training  a  pilot  in  a  virtual  environment.  The  station  is  equipped  with  a  head-mounted 
display  (HMD)  with  headset  and  a  mock-up  of  the  LSO  console  including  active  switches  and 
levers. 

The  Equipment  Rack  Station2  houses  video  distribution  equipment. 

The  Motion  Platform  Power  Station  provides  power  supply  and  power  control  equipment  for  the 
Motion  Platform  Subsystem. 

The  Equipment  Rack  Stationl  houses  the  Motion  Platform  Control  Computer,  voice  mixer  and 
sound  generation  equipment. 

The  Medium  Frequency  Station  houses  two  medium  frequency  loud  speakers  on  a  stand. 

The  Audio  Communication  Subsystem  Station  provides  the  necessary  facilities  for  the  instructor 
operator  and  the  pilot  trainee  to  exchange  audio  communications  during  a  training  exercise. 
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1.3 


System  Overview 


1.3.1  Background 

Currently,  Canadian  Forces  (CF)  pilots  flying  the  Sea  King  helicopter  learn  to  land  on  the  flight 
deck  of  a  CPF  through  practice  at  sea.  Although  the  training  community  has  used  a  Sea  King 
helicopter  simulator  at  CFB  Shearwater  for  more  than  thirty  years,  it  does  not  have  a  visual 
display  and  consequently  cannot  be  used  for  training  visually  guided  tasks.  Modem  simulators  are 
available  with  non-FIUD  visual  displays,  but  they  are  expensive  to  procure  and  maintain.  The 
acquisition  cost  of  a  typical  commercial  simulator  can  exceed  $20  million  Canadian.  Although 
expensive,  high-end  simulators  are  cost-effective  for  some  training  operations  when  the  high 
costs  and  risks  associated  with  operational  training  are  considered.  Flowever,  the  large  acquisition 
price,  the  high  maintenance  costs,  the  small  maritime  pilot  population  and  limited  Sea  King 
lifespan,  as  well  as  geographical  considerations  are  likely  factors  that  dissuade  the  purchase  of 
high-end  simulators  for  training  deck  landing  skills. 

In  1994,  DRDC  Toronto  was  requested  by  CF  to  investigate  the  potential  use  of  low  cost,  virtual 
reality  technologies  for  this  puipose,  following  a  successful  demonstration  of  these  technologies 
for  training  ship  handling  skills  and  reductions  of  sea  time. 

Landing  on  the  deck  of  a  CPF  in  high  sea  states  is  considered  one  of  the  most  challenging 
visually  guided  tasks  perfomied  by  any  helicopter  pilot  in  the  CF.  It  requires  fine  motor  skills, 
exceptional  judgement  and  precise  manoeuvring  techniques.  Moreover,  good  depth  perception  is 
an  essential  element  and  a  necessity  for  this  task  as  the  helicopter  blades  are  within  5  metres  of 
the  ship's  hangar  face  in  the  properly  landed  position.  The  physics-based  modelling  aspects  are 
also  formidable  challenges,  since  in  addition  to  the  aerodynamic  modelling  of  the  Sea  King,  the 
modelling  of  the  ship's  dynamics,  interactions  with  the  wind  as  affected  by  the  ship's 
superstructure,  as  well  as  modelling  of  the  undercarriage  and  its  contact  with  the  deck  surface 
must  be  included. 

The  simulator  design  goals  are  to  include  affordability,  portability,  modularity  and  low 
maintenance.  Low  cost  can  be  partially  achieved  by  employing  commercial  off-the-shelf  (COTS) 
components  intended  for  the  entertainment  market,  rather  than  components  specialized  for  high- 
end  simulators. 

A  detailed  description  of  the  HelMET/HDLS  development  can  be  found  in  [References  a,  b]. 


1.3.2  Simulator  System  Description 

The  simulator  design  builds  on  common  COTS  components  supplemented  with  specific  aircraft 
parts  from  the  Sea  King  helicopter.  The  Pilot  Station  includes  an  adjustable  Sea  King  seat  and 
primary  flight  control  equipment  linked  to  the  Simulation  Computer  Subsystem  and  various 
subsystems  for  sensory  cueing.  The  Simulation  Computer  Subsystem,  flight  control  components, 
and  other  subsystems  are  further  discussed,  along  with  their  general  characteristics.  The  pilot's 
flight  controls,  including  tail  rotor  pedals,  collective  pitch  lever,  and  cyclic  pitch  stick  were 
obtained  from  the  CF  supply  system  or  were  built  from  technical  drawings.  Sensory  cues  are 
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provided  by  a  visual  subsystem,  motion  platform  subsystem,  and  sound  and  vibration  subsystems. 
Control  of  pilot  training  is  conducted  via  the  Instructor  Operator  Station  and  Audio 
communication  Subsystem. 


The  simulator  system  block  diagram  is  shown  in  Figure  2.  The  simulator  consists  of  the  following 
major  subsystems  [References  a,  b]: 


•  Motion  Platform  Subsystem 

•  Flight  Control  Component  Subsystem 

•  Visual  Subsystem 

•  Video  Distribution  Subsystem 

•  Sound  Subsystem 

•  Vibration  Subsystem 

•  Audio  Communication  Subsystem 

•  Simulation  Computer  Subsystem 

•  Instructor  Operator  Station  Subsystem 

•  Landing  Signals  Officer  Station  Subsystem 

•  Local  Area  Network. 


The  Motion  Platform  Subsystem,  a  six-degree  of  freedom  (DOF)  motion  base  unit,  provides  the 
necessary  motion  cues  (roll,  pitch,  yaw,  heave,  surge  and  sway)  for  a  simulated  helicopter. 


The  Flight  Control  Component  Subsystem  provides  user  control  interfaces  to  three  unique  flight 
control  characteristics:  the  vertical  control,  the  horizontal  control,  and  the  heading  control. 


The  Visual  Subsystem  provides  the  pilot  with  a  view  of  simulated  environment.  It  consists  of  a 
head  tracking  device,  an  image  generator,  and  a  head  mounted  display.  The  head  tracking  device 
determines  the  position  and  orientation  of  the  pilot's  head,  which  is  used  to  determine  his/her 
point  of  view.  These  measurements  are  passed  to  the  image  generator  that  renders  the  images 
within  this  field  of  view  (FOV),  and  transmits  the  images  to  the  Video  Distribution  Subsystem. 
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The  Video  Distribution  Subsystem  accepts  display  images  in  RGB  video  signals  from  the  Image 
Generator  and  distributes  images  to  the  HMD  display  for  pilot  viewing  and  the  instructor  display 
repeater  for  instructor  viewing. 


The  Sound  Subsystem  drives  the  sound  and  vibration  subsystems’  speakers  and  delivers 
continuous  auditory  cues  as  a  function  of  the  Sea  King's  simulated  flight  regime  based  on  data 
received  from  the  Simulation  Computer  Subsystem. 


Like  the  Sound  Subsystem,  the  Vibration  Subsystem  provides  continuous  cues  to  supplement  the 
Motion  Platform  Subsystem.  The  Vibration  Subsystem  is  to  provide  the  higher  frequency 
vibration  environments  that  are  not  normally  provided  through  the  Motion  Platform  Subsystem. 


The  Audio  Communication  Subsystem  provides  the  necessary  audio  communication  interfaces 
between  the  pilot  and  instructor-operator. 


The  Simulation  Computer  Subsystem  executes  the  helicopter  simulation  model  and  management 
utilities,  uses  the  pilot's  controls  to  calculate  the  motion  dynamics,  determines  the  pilot's  point  of 
view  from  tracking  head  movements  and  generates  the  graphics  for  the  pilot's  visual  display  and 
the  Instructor  Operator  Station  repeater  monitors. 


The  Instructor  Operator  Station  communicates  with  the  Simulation  Computer  Subsystem  for  the 
simulation  control. 


The  Landing  Signals  Officer  Station  communicates  with  the  Simulation  Computer  Subsystem  for 
the  simulation  status  and  provides  the  Landing  Signals  officer  with  visual  representation  of  the 
virtual  scene.  It  also  accepts  input  via  the  LSO  console  and  provides  this  data  to  the  simulation 
computer  to  update  the  simulation. 


The  Simulation  Local  Area  Network  provides  communication  among  the  five  major  computers 
(Motion  Platform  Control  Computer,  Simulation  Computer,  Instructor  Computer,  Landing 
Signals  Officer  Computer,  Audio  Communication  Subsystem  Computer  1  -  Digital  Audio 
Conferencing  and  Audio  Communication  Subsystem  Computer  2  -  Digital  Audio  Conferencing 
&  Effects)  that  host  the  applications  software  for  the  simulation.  The  Audio  Local  Area  Network 
provides  communication  between  Audio  Communication  Subsystem  Computer  1  -  Digital  Audio 
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Conferencing  and  Audio  Communication  Subsystem  Computer  2  -  Digital  Audio  Conferencing 
&  Effects  for  hosting  digital  audio  conference  software. 
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Figure  2  Simulator  Block  Diagram 
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1.4  Document  Overview 


This  Software  Product  Specification  (SPS)  provides  the  inventory  of  software  contents  released 
and  software  support  information.  A  brief  outline  of  the  contents  of  this  document  is  given 
below: 

Section  1  -  Scope 

This  section  describes  the  identification,  system  overview,  and  document  overview  for  the 
simulator. 

Section  2  -  Referenced  Documents 

This  section  lists  by  document  number,  title,  revision,  and  date  all  documents  referenced  in  this 
document. 

Section  3  -  Requirements 

This  section  lists  the  inventory  of  material  released  and  software  contents. 

Section  4  -  Software  Support  Information 

This  section  provides  information  regarding  installation  procedures,  compilation/build 
procedures,  modification  procedures,  computer  hardware  resource  utilization,  and  possible 
problems  and  known  errors. 

Section  5  -  Notes 

This  section  contains  general  information. 

Appendices 

The  appendices  provide  information  published  separately  for  convenience  in  document 
maintenance.  The  appendices  of  this  document  consist  of: 


•  Appendix  A  -  Directory  Structure 

•  Appendix  B  -  SMART  Makefile  Structure 

•  Appendix  C  -  MatrixX  Notes  on  Sea  King  Simulator 

•  Appendix  D  -  Modifications  of  Visual  Models. 
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2  Referenced  Documents 


The  following  government  and  non-govemment  documents  are  referenced  in  this  manual: 


a.  DRDC  Toronto  Specification 

b.  DRDC  Toronto  Technical  Report 

c.  DRDC  Toronto  Technical  Report 

d.  DRDC  Toronto  Technical  Report 

e.  DRDC  Toronto  Technical  Report 

f.  DRDC  Toronto  Document:  CR2002-027 
Atlantis  Document:  ED990-01 155 

g.  DRDC  Toronto  Document:  CR2002-022 
Atlantis  Document:  ED997-00368 

h.  DRDC  Toronto  Document:  CR2002-028 
Atlantis  Document:  ED997-00369 

i.  DRDC  Toronto  Document:  CR2002-031 
Atlantis  Document:  VD905-03128 

j.  DRDC  Toronto  Document:  CR2002-032 
Atlantis  Document:  ED999-01 183 

k.  Servos  and  Simulation  Inc. 

l.  Bill  Spitzak  and  others 

m.  MathWorks  Inc. 

n.  MathWorks  Inc. 

o.  MathWorks  Inc. 


Helicopter  Deck  Landing  Simulator  & 
Landing  Signalling  Officer  Simulator 
Preliminary  Specification  (Updated) 

Helicopter  Deck  Landing  Simulator 
Technology  Demonstrator 
by  F.A.  Lue  and  L.E.  Magee 

Introduction  to  MultiGen  Creator 

MultiGen  Creator  Modelling  Techniques 
and  Performance  Optimization 

Developing  Maintainable  Code 

Helicopter  Maritime  Environment  Trainer 
Software  Test  Description 

Helicopter  Maritime  Environment  Trainer 
Operator  Manual 

Helicopter  Maritime  Environment  Trainer 
Maintenance  Manual 

Helicopter  Maritime  Environment  Trainer 
Version  Description  Document 

Helicopter  Maritime  Environment  Trainer 
Data  Package 

Six  Degrees  Of  Freedom  Motion  Platform 
Maintenance  Manual 

FLTK  1.0.10  Programming  Manual 

MatrixX  Online  Documentation  CD 

MatrixX  CD-ROM  Installation  Procedure 

MatrixX  Getting  Started  (Windows)  Manual 
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p.  MathWorks  Inc. 

q.  MathWorks  Inc. 

r.  MultiGen  Paradigm 


s.  MultiGen  Paradigm 


t.  MultiGen  Paradigm 


MatrixX  System  Administrator's  Guide 
(Windows) 

MatrixX  Autocode  Application  Notes 

“Creating  Models  for  Simulations, 

Version  2.4  for  Windows  and  IRIX  August 
2000”,  MultiGen  Creator  user  manual,  San  Jose, 
CA 

“Desktop  Tutor”,  MultiGen  Creator  user 
manual,  San  Jose,  CA 

“MultiGen  Creator  user  manual,  3d  Real-time 
simulation”,  MultiGen  Creator  user  manual,  San 
Jose,  CA 
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3  Requirements 


3.1  Inventory  of  Material  Released 

The  simulator  software  consists  of  the  following  two  major  Computer  Software  Configuration 
Items  (CSC1): 


•Support  Software  and  Tools  CSCI 
•HelMET  Operational  Software  CSCI. 

Descriptions  of  these  CSCIs  can  be  found  in  the  Helicopter  Maritime  Environment  Trainer 
Operator  Manual  [Reference  i]. 

The  following  sections  describe  the  inventory  of  material  released  for  these  two  CSCIs. 

3.1.1  Support  Software  and  Tools  CSCI 

The  Support  Software  and  Tools  CSCI,  a  collection  of  software  packages,  consists  of  the 
following  major  Computer  Software  Component  (CSC): 

•  Purchased  COTS  CSC 

•  Freeware  OTS  CSC 

•  Customized  OTS  CSC 

3. 1.1.1  Purchased  COTS 

•  MS-DOS  Operating  System  (OS) 

•  OpenGL  Performer  for  Linux 

•  RedHawk  Linux  Operating  System  (OS) 

•  CerealBox  Driver. 


3. 1.1. 1.1  MS-DOS  Operating  System 

Table  1  lists  the  software  material  released  for  the  MS-DOS  Operating  System: 

Table  1  MS-DOS  Operating  System  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

" 

MS-DOS  Operating  System  Version 
6.22 

1 

3 

2 
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(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  Compact  Disc 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


3.1. 1.1.2  OpenGL  Performer  for  Linux  V3.1.1 


lists  the  software  material  released  for  the  OpenGL  Performer  for  Linux: 

Table  2:  Open  GL  Performer  for  Linux  V3.1.1 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

OpenGL  Performer  for  Linux  V3. 1. 1 

3 

3 

2 

(1)  Media  Types: 

(2)  Duplication 

(3)  Licence 

1-3.5  inch,  1 .44Mb  DOS  formatted  floppy  disk  1  -  For  backup  purpose  only  1  -  N/A 

2  -  8mm  DAT,  DOS  formatted  2  -  Unlimited  2  -  Refer  to  Third  Party  contract 

3  -  Compact  Disc  3  -  Refer  to  3rd  party  licence 

4  -  Downloaded  from  Internet 


3.1. 1.1. 3  RedHawk  Linux  Operating  System 


lists  the  software  material  released  for  the  Redhawk  Linux  Operating  System: 
Table  3:  :RedHawk  Linux  Operating  System 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

RedHawk  Linux  Operating  System  V4.0 

3 

3 

2 

(1)  Media  Types: 

(2)  Duplication 

(3)  Licence 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  Compact  Disc 

4  -  Downloaded  from  Internet 


1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


1  -  N/A 

2  -  Refer  to  Third  Party  contract 


3.1. 1.1.4  Cereal  Box  Driver 
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lists  the  software  material  released  for  the  CerealBox  Driver  library. 

Table  4  CerealBox  Driver  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

CerealBox  Driver  v  307 

3 

3 

2 

(1)  Media  Types: 

1-3.5  inch,  1 ,44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Operational  SW  CSCI) 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


4  -  Downloaded  from  Internet  -  http://www.bgsystems.com/ 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.1. 2  Freeware  OTS  CSC 

The  Freeware  OTS  CSC  consists  of  the  following  major  components: 

•  Red  Hat  Linux  Operating  System 

•  DMSO  HLA  Run-time  Infrastructure  (RTI) 

•  Parallel  Virtual  Machine  (open  source) 


3. 1.1. 2.1  RedHat  Linux  Operating  System 


lists  the  software  material  released  for  the  Linux  Operating  System: 

Table  5  Linux  Operating  System  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

Linux  RedHat  Operating 
System  Version  8.0 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  Compact  Disc 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -  N/A 

2  -  Refer  to  Third  Party  contract 
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3. 1.1. 2. 2  DMSO  HLA  Run-time  Infrastructure  (RTI) 


lists  the  software  material  released  for  the  DMSO  HLA  RTI: 

Table  6  DMSO  HLA  Run-time  Infrastructure  (RTI) 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

HLA  RTI  1.3  NGv6 

3 

3 

2 

1)  Media  Types: 

1-3.5  inch,  1 ,44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Support  SW  CSCI) 

4  -  Downloaded  from  Internet  -  http://sdc.dmso.mil/ 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.1.2. 3  Parallel  Virtual  Machine 


lists  the  software  material  released  for  the  Parallel  Virtual  Machine  (PVM): 

Table  7  PVM  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

Parallel  Virtual  Machine  3.4.3 

3 

3 

2 

1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Support  SW  CSCI) 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -  N/A 

2  -  Refer  to  Third  Party  contract 


3.1. 1.3  Customized  OTS 

The  Customized  OTS  CSC  consists  of  the  following  major  software  packages.  These  packages 
have  been  customized  to  suit  the  needs  of  the  simulator  software. 

•  Motion  Platform  Control  Computer  Software 

•  FREDYN 

•  Fast  Light  Tool  Kit 
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Fast  Light  User  Interface  Designer 
Open  Audio  Library 


3. 1.1. 3.1  Servos  and  Simulation  Motion  Platform  Software 

Table  8  lists  the  software  material  released  for  the  Servos  and  Simulation  Motion  Platform 
Software: 


Table  8  Motion  Platform  Software  inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

83-0346-004 

3Com  EtherDisk  Version  3.3 

1 

3 

2 

- 

FTP  Software  Inc  PC/TCP  Kernel 
v4.1  (K-210)  Disk  1  of  1 

1 

3 

2 

- 

FTP  Software  Inc  PC/TCP  Kernel 
v4.1  (K-210)  Disk  1  of  3 

1 

3 

2 

- 

FTP  Software  Inc  PC/TCP  Kernel 
v4.1  (K-210)  Disk  2  of  3 

1 

3 

2 

FTP  Software  Inc  PC/TCP  Kernel 
v4.1  (K-210)  Disk  3  of  3 

1 

3 

2 

- 

Servos  and  Simulation  6-DOF  Software 
Disk 

1 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Operational  SW  CSCI) 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


3.1. 1.3.2  FREDYN 

Table  9  lists  the  software  material  released  for  the  FREDYN: 

Table  9  FREDYN  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 
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- 

Fredyn  6.0 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Operational  SW  CSCI) 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.1. 3. 3  Fast  Light  Tool  Kit 

Table  10  lists  the  software  material  released  for  the  Fast  Light  Took  Kit  (FLTK): 

Table  10  FLTK  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

FLTK  1.0.10 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Support  SW  CSCI) 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -  N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.1. 3.4  Fast  Light  User  Interface  Designer 

Table  1 1  lists  the  software  material  released  for  the  Fast  Light  User  Interface  Designer  (FLUID): 
Table  11  FLUID  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

FLUID  vl.0.9  +  DRDC  patch  04 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Operational  SW  CSCI) 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -  N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.1. 3. 5  Open  Audio  Library 

Table  12  lists  the  software  material  released  for  the  Open  Audio  library  (OpenAL): 

Table  12  OpenAL  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 
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- 

Open  Audio  Library  (12  Feb  01) 

3 

3 

2 

( 1 )  Media  Types:  (2)  Duplication  (3)  Licence 

1-3.5  inch,  1 ,44Mb  DOS  formatted  floppy  disk  1  -  For  backup  purpose  only  1  -  N/A 

2  -  8mm  DAT,  DOS  formatted  2  -  Unlimited  2  -  Refer  to  Third  Party  contract 

3  -  CD  (HelMET  Support  SW  CSCI)  3  -  Refer  to  3rd  party  licence 

4  -  Downloaded  from  Internet  -  http://www.openal.org/ 


3.1.2  HelMET  Operational  Software  CSCI 

3. 1.2.1  Software  Development  Tools 

Some  of  non-deliverable  software  development  tools  include: 

•  MATRIXx 

•  MultiGen  Creator 


3.1. 2.1.1  MATRIXx 


lists  the  software  material  released  for  the  MATRIXx. 

Table  13  MATRIXx  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

090-0017-007 

MATRIXx  6.2.2  for  NT4.0 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  Compact  Disc 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -  N/A 

2  -  Refer  to  Third  Party  contract 


3. 1.2. 1.2  MultiGen  Creator 


lists  the  software  material  released  for  the  MultiGen  Creator. 
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Table  14 


MultiGen  Creator  Inventory  of  Material  Released 


Part  Number 

Media  Title 

Media  Type 

Duplication 

Licence 

- 

MultiGen  Creator  Visual  Data 
Base  Modelling  System, 
Version  2.4.1  OpenFlight 
Version  15.70 

3 

3 

2 

(1)  Media  Types: 

1  -  3.5  inch,  1.44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  Compact  Disc 

4  -  Downloaded  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 
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4  Software  Support  Information 


4.1  Related  Documents 

TM  20 1 1  -048  Helicopter  Maritime  Environment  Trainer 

Software  Test  Document 


TM  2011-047 


Helicopter  Maritime  Environment  Trainer 
Operator  Manual 


TM  2011-049 


Helicopter  Maritime  Environment  Trainer 
Maintenance  Manual 


TM  2011-051 


Helicopter  Maritime  Environment  Trainer 
Version  Description  Document 


TM  2011-052 


Helicopter  Maritime  Environment  Trainer 
Data  Package 


4.2  Installation  Instructions 

4.2.1  Commercial  Off-the-Shelf  CSCI  Installation  Instructions 

4.2. 1.1  MS-DOS  Operating  System 

The  MS-DOS  6.22  runs  on  a  100  MHz  Pentium  Single  Board  Computer  (SBC)  for  the  6-DOF 
Motion  Platform. 

Information  on  installing  the  OS  is  described  in  the  MS-DOS  6.22  Installation  Manual. 


4.2. 1.2  Red  Hat  Linux  Operating  System 

Red  Hat  Linux  8.0  runs  on  Intel  X86  computers  for  the  10S,  LSO,  Audio  Subsystem  Computerl 
and  Audio  Subsystem  Computer2. 
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Information  on  installing  the  OS  is  described  in  the  Official  Red  Hat  Linux  8.0  Installation  Guide 
which  is  available  and  downloadable  from  www.redhat.com.  Further  information  is  available  in 
the  RH8.pdf  file  on  the  HelMET  Support  Software  Install  CD  for  Linux. 

4.2. 1.3  RedHawk  Linux  Operating  System 

The  RedHawk  Linux  4.0  runs  on  a  Concurrent  Computer  Corporation  Imagen  Computer  system 
which  houses  4  Dual  core  AMD  processors  that  is  used  as  the  simulation  computer. 

Information  on  installing  the  OS  is  described  on  the  Redhawk  Installation  CDs. 


4.2. 1.4  DMSO  HLA  Run-time  Infrastructure  (RTI) 

The  HLA  RTI  Next  Generation  1.3  (RTI-NG  1.3)  from  Defence  Modelling  Simulation 
Organization  (DMSO)  and  Science  Application  International  Corporation  (SAIC)  is  an 
implementation  of  the  High  Level  Architecture  Specification,  Version  1.3.  The  RTI  provides  a 
collection  of  common  services  used  to  support  the  modelling  and  simulation  applications.  All  of 
these  services  are  accessed  through  a  standard  application  programming  interface  (API). 

The  HLA  RTI  is  included  in  the  HelMET  Support  Software  Installation  CD.  Information  on 
installing  the  HelMET  Operational  Software  CSCI  is  described  in  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 


4.2. 1.5  OpenGL  Performer  for  Linux  3.1.1 

OpenGL  Performer  is  proprietary  3D  Graphics  rendering  Software  from  Silicon  Graphics 
International  (SGI),  this  software  runs  on  all  HelMET  computers  that  display  images  from  the 
Virtual  World  (Simulation,  IOS,  and  LSO  computers). 

Information  on  installing  the  HelMET  Operational  Software  CSCI  is  described  in  the  RH8.pdf 
file  on  the  HelMET  Support  Software  Install  CD  for  Linux. 


4.2. 1.6  CerealBox  Driver 

The  Cereal  Box  Driver  Library,  from  BG  Systems  Inc,  provides  the  necessary  functions  to 
configure  and  interface  with  the  CerealBox  hardware. 

The  CerealBox  driver  is  included  in  the  HelMET  Operational  Software  CSCI  CD.  Information  on 
installing  the  HelMET  Operational  Software  CSCI  is  described  in  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 
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4.2. 1.7  Open  Audio  Library 

The  Open  Audio  Library  (OpenAL),  a  free  distribution  software  package  from  Loki 
Entertainment  Software,  is  an  Application  Programming  Interface  (API)  for  interactive,  primarily 
spatialized  audio. 

The  Open  Audio  library  is  included  in  the  HelMET  Support  Software  Install  CD.  Information  on 
installing  the  HelMET  Operational  Software  CSC1  is  described  in  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 


4.2. 1.8  Parallel  Virtual  Machine 

The  Parallel  Virtual  Machine  (PVM),  a  free  distribution  software  package  from  Oak  Ridge 
National  Laboratory,  allows  a  computer  to  spawn  processes  on  another  computer. 

The  Parallel  Virtual  Machine  is  included  in  the  HelMET  Support  Software  CSC1  CD.  Information 
on  installing  the  HelMET  Operational  Software  CSC1  is  described  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 


4.2. 1.9  Servos  and  Simulation  Motion  Platform  Software 

The  Motion  Platform  Control  Computer  Subsystem  is  an  IBM  Compatible  PC,  which  is  equipped 
with  the  following  system  environments: 

1 .  Hardware  Environment 

■  A  100  MHz  Pentium  Single  Board  Computer 
passive  backplane  chassis 

■  A  8  Mbytes  of  ram  memory 

■  One  3.5  inch  Hard  Disk  Drive  and  one  3.5  inch 

■  One  VGA  Display  Monitor 

■  One  standard  keyboard 

■  One  RS-232  serial  port 

■  One  Centronics  parallel  port 

■  One  C1O-DDA06/12  Digital  I/O  board  for  communicating  with  the  SBC 

■  One  C1O-RELAY08  Relay  board. 

2.  Software  Environment 


(SBC)  mounted  in  slot  1  of  the 


floppy  disk  drive 
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■  Microsoft  MS-DOS  version  6.22 

■  An  Ethernet  packet  driver  for  the  specified  Ethernet  card 

■  FTP  Software  PC/TCP  for  DOS  software 

■  Servos  and  Simulation  Incorporation’s  6-DOF  software  disk. 


The  following  steps  must  be  performed  to  install  the  software  of  the  Motion  Platform  Control 
Computer  Subsystem.  Additional  information  on  the  software  of  the  Motion  Platform  Control 
Computer  Subsystem  is  described  in  the  Six  Degrees  of  Freedom  Motion  Platform  Maintenance 
Manual  [Reference  k] 


1.  Set  computer’s  BIOS  to  a  standard  setup,  disabling  the  cache  where  the  Ethernet  card 
resides  (not  necessary  on  plug  and  play  cards). 

2.  Format  hard  drive  using  MS-DOS  6.22  and  install  operating  system  in  the  C:\DOS 
subdirectory. 

3.  Install  the  6-DOF  software  with  the  following  command  from  the  DOS  prompt: 

XCOPY  A:\*.*  C:V. *  /s/e/v 

4.  Install  the  Ethernet  card’s  supporting  software  with  its  packet-drive  support  files. 

5.  Install  FTP’s  PC/TCP  for  DOS. 

6.  Setup  the  network  using  PC/TCP’s  provided  configuration  manager. 

7.  Add  the  ‘;C:\6DOF;’  to  your  path  in  the  autoexec.bat. 

8.  Add  ‘Go’  as  the  last  line  in  the  autoexec.bat. 

9.  Reboot  the  machine  to  start  the  system. 

10.  Edit  C:\6DOF\GO.BAT  to  reflect  the  host’s  IP  address  and  port  number. 

11. 

4.2.1.10  FREDYN 

The  FREDYN  Version  6.0  from  Maritime  Research  Institute  Netherlands  (MARIN)  is  a  software 
package  used  for  the  ship  dynamics  within  the  simulator. 
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The  Fredyn  software  is  included  in  the  HelMET  Operational  Software  CSC1  CD.  Information  on 
installing  the  HelMET  Operational  Software  CSC1  is  described  in  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 


4.2.1.11  Fast  Light  Tool  Kit 

The  Fast  Light  Tool  Kit  (FLTK),  a  free  distribution  software  package,  is  used  to  provide  the 
necessary  GUI  for  controlling  the  simulation  exercise. 


The  Fast  Light  Tool  Kit  is  included  in  the  HelMET  Support  Software  CSC1  CD.  Information  on 
installing  the  HelMET  Operational  Software  CSC1  is  described  in  the  RH8.pdf  file  on  the 
HelMET  Support  Software  Install  CD  for  Linux. 


4.2.1.12  Fast  Light  User  Interface  Designer 

The  Fast  Light  User  Interface  Designer  (FLUID),  a  free  distribution  software  package,  is  a 
graphical  editor  that  is  used  to  produce  FLTK  source  code.  The  FLUID  editor  can  be  used  to  edit 
and  save  its  state  in  FLUID  (.fl)  files. 


The  Fast  Light  User  Interface  Designer  is  included  in  the  HelMET  Support  Software  CSC1  CD. 
Information  on  installing  the  HelMET  Operational  Software  CSC1  is  described  in  the  RH8.pdf 
file  on  the  HelMET  Support  Software  Install  CD  for  Linux. 


4.2.1.13  MATRIXx 

The  MATRIXx  6.2.2  from  MathWorks  Inc.  is  a  suite  of  development  tools  for  modelling  Sea 
King  aerodynamics.  The  MATRIXx  is  installed  in  a  NT4.0  environment. 

Information  on  installing  MATRIXx  6.2.2  is  described  in  the  MATRIXx  Installation  Manual. 

4.2.1.14  MultiGen  Creator 

The  MultiGen  Creator  Visual  Data  Base  Modelling  System  from  MultiGen  Paradigm  is  a 
software  toolset  for  creating  a  highly  optimised,  high-fidelity,  real-time  3D  database  for  use  in 
visual  simulation,  interactive  games,  urban  simulation,  and  other  applications. 
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Information  on  installing  MultiGen  Creator  is  described  in  the  MultiGen  Creator  Getting  Started 
manual. 


4.2.2  HelMET  Operational  Software  CSCI  Installation  Instructions 

Descriptions  of  the  HelMET  Operational  Software  CSCI  can  be  found  in  the  Helicopter  Maritime 
Environment  Trainer  Operator  Manual  [Reference  i]. 

Information  on  installing  HelMET  Operational  Software  CSCI  is  described  in  the  Helicopter 
Maritime  Environment  Trainer  Operational  Software  CSCI  Version  Description  Document 
[Reference  k]. 


4.3  Compilation/Build  Procedures 

The  HelMET  Operational  Software  CSCI  runs  in  the  LINUX  environment.  The  following 
sections  describe  the  compilation/build  environment  and  process  for  the  HelMET  Operational 
Software  CSCI. 


4.3.1  Compilation/Build  Environment 

4.3. 1.1  Compilation/Build  Environment  On  LINUX 

The  version  of  HelMET  Operational  Software  CSCI  requires  the  following  system  environment 
to  be  able  to  compile/build  in  a  LINUX  environment: 

Hardware  Environment: 

•  IBM  Compatible  PC: 

♦  Intel  Pentium  computer  (or  equivalent) 

♦  at  least  512  MB  RAM 

♦  (Audio  computers  only)  Creative  Labs  Sound  Blaster  Live  sound  card 

♦  Nvidia  GeForce  2  or  newer 

♦  NIC 

♦  CD-ROM  drive  or  FTP  client 

♦  40  GB  Hard  Drive  or  better. 
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Software  Environment: 


Table  15  Compilation/Build  Software  Environments  on  LINUX 


Part  Number 

Media  Title 

Media 

Type 

Duplication 

Licence 

Web  Site 

- 

RedHat  Linux  8.0 
or  Redhawk  Linux 

3 

3 

2 

http://www/redhat.com 

- 

The  Past  Light 
Toolkit  fltk  1.0.10 

3 

3 

2 

http  ://www.  fltk.  org 

- 

Past  Light  User 
Interface  Designer 
fluid  1.0.9 

3 

3 

2 

http  ://www.  fltk.  org 

- 

Open  Audio 
Library  OpenAL 
(12  Feb  01) 

3 

3 

2 

http://www.openal.org 

- 

Parallel  Virtual 
Machine  pvm  3.4.3 

3 

3 

2 

http://www.csm.oml.gov/ 
pvm/pvm  home.html 

- 

OpenGL  Performer 
V3.1.1 

3 

3 

2 

http://www.sgi.com 

- 

DMSO  HLA  RTI 

1.3  NGv6 

3 

3 

2 

http  ://sdc .  dmso.mil/ 

(out  of  date) 

(1)  Media  Types: 

1-3.5  inch,  1 ,44Mb  DOS  formatted  floppy  disk 

2  -  8mm  DAT,  DOS  formatted 

3  -  CD  (HelMET  Operational  SW  CSCI) 

4  -  Download  from  Internet 


(2)  Duplication 

1  -  For  backup  purpose  only 

2  -  Unlimited 

3  -  Refer  to  3rd  party  licence 


(3)  Licence 

1  -N/A 

2  -  Refer  to  Third  Party  contract 


4.3.2  Compilation/Build  Process 

The  software  source  code  is  compiled/built  using  the  linux  (gmake)  make  utility.  The  linux 
gmake  utility  is  a  tool  for  organizing  and  facilitating  the  update  of  executables  or  other  files  that 
are  built  from  one  or  more  constituent  files.  The  make  execution  command  uses  the  user-defined 
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Makefile  to  create  or  update  one  or  more  target  files  based  on  the  most  recent  modify  dates  of  the 
required  files.  This  Makefile  provides  instructions  on  how  source  files  are  compiled.  When  the 
make  command  is  executed,  it  looks  for  a  Makefile  in  the  current  directory.  If  a  Makefile  cannot 
be  found,  the  make  command  will  look  for  other  filename  such  as  makefile.  (However,  to  make 
the  build  process  be  consistent,  the  filename  Makefile  is  always  used  throughout  the  project).  In 
the  case  that  the  command  cannot  locate  a  Makefile,  the  make  process  will  fail  and  a  message 
similar  to  “No  targets  specified  and  not  makefile  found”  will  be  displayed. 


In  the  software,  the  compilation/build  process  is  further  enhanced  with  the  use  of  the  build  script. 
The  build  script  is  provided  with  a  variety  of  options  for  the  user  to  choose  during 
compilation/build  process.  The  options  are  detailed  as  follows: 

•  build  clean  -  clean  out  savdb,  smart,  rhs  and  all  hdls  federates  and  builds  from  scratch 

•  build  all  -  build  savdb,  smart  and  rhs  libraries  and  helo,  Iso  and  ios,  drdc  helo  federates 
and  audio  server  (executable) 

•  build  savdb  clean  -  clean  out  savdb  libraries  and  then  builds  savdb 

•  build  savdb  -  build  savdb  libraries 

•  build  smart  clean  -  clean  out  smart  libraries  and  then  build  smart  libraries 

•  build  smart  -  build  smart  libraries 

•  build  rhs  clean  -  clean  out  all  hdls  federates  and  then  build  rhgs  librarries  and  all  federates 

•  build  rhs  -  build  rhs  librarries  and  all  federates 

•  build  helo  -  build  Helo  Federate 

•  build  ios  -  build  ios  Federate 

•  build  Iso  -  build  Iso  Federate 

When  the  build  script  is  invoked,  it  will  call  upon  make  command  with  appropriate  Makefiles  that 
define  rules  for  making  target  files.  The  software  directory  structure  is  described  in  Appendix  A 
of  this  document.  Note  that  in  each  of  the  source  directories,  there  is  a  user-defined  Makefile. 

An  overview  of  the  software  Makefile  structure  is  described  in  Appendix  B  of  this  document. 


4. 3. 2.1  Illustration  of  Build  Process 

The  process  of  building  SMART  library  is  used  here  for  illustration  purpose  only.  When  a 
command  “build  smart”  is  entered  in  the  command  line,  the  build  script  executes  make  command 
which  calls  upon  the  Makefile  file  in  the  ~/local/smart/src  directory.  This  Makefile  defines  all 
sub-directories  to  be  made  and  includes  the  SMART  makedirs.mk  for  the  rules  to  make  these 
sub-directories. 
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The  SMARTmakedirs.mk  file  loops  through  the  subdirectories  calling  make  with  the  Makefile 
in  each  of  the  subdirectories.  The  Makefile  in  each  sub-directory  defines  the  rules  and  target  / 
stub  to  be  built.  Each  target  or  stub  is  associated  with  a  .mk  file.  The  individual  .mk  file  defines 
the  library  name  and  object  files  to  be  built.  It  also  contains  definition  and  information  on  how  to 
process  the  build  requests  to  create  a  binary  executable,  a  static  library,  a  dynamic  library  or 
object  files. 


The  individual  .mk  file  also  includes  the  SMARTmakelibdefs.mk  and  SMARTmakelib.mk 
files.  The  SMART  makelibdefs.mk  file  defines  the  locations  of  the  object  (.0)  and  dependency 
(.d)  directories.  It  also  includes  the  SMARTdefs.mk  and  SMART  libs.mk  files.  The 
SMARTdefs.mk  defines  all  compilation  utilities,  shell  commands  and  compiler  flags.  The 
SMART  lib.mk  defines  variables  for  the  standard  system  libraries  and  all  smart  libraries 
provided  by  the  SMART. 


The  SMARTmakelib.mk  includes  the  SMARTmakestaticlib.mk  file.  The 

SMARTmakestaticlib.mk  file  defines  rules  for  making  the  SMART  library  and  also  includes  the 
SMART  sources.mk,  SMART  deps.mk  and  SMART  rules.mk  files  which  define  the  rules  for 
building  the  source,  dependency  and  object  files. 


The  following  tree  diagram  illustrates  the  process  of  building  the  SMART  library: 
build  smart 


L> 


Makefile  (local/smart/src) 
SMART  makedirs.mk 


u 


u  Makefile  (in  each  subdirectory,  e.g.  DataTree,  Performer,  etc) 
I— ^  SMART  maketargets.mk 

1— ►(for  each  individual  .mk  file) 


SMARTmakelibdefs.mk 
SMARTdefs.mk 

SMARTdefslinux.mk 
SMART  libs.mk 
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— ►  SMART  makelib.mk 


SM 


ARTmakestaticlib.mk 
SMARTsources.mk 
SMARTdeps.mk 
^  SMART  rules.mk 


4. 3. 2. 2  Compilation/Build  Process  On  LINUX 


4. 3. 2. 2.1  Setting  Up  Build  Machine 

Assuming  that  the  build  machine  has  had  RedHat  linux  8.0  previously  installed.  The  procedure 
for  setting  up  Build  Machine  is  described  below: 


1 .  Log  on  to  the  computer  as  root. 

2.  Insert  the  “HelMET  Support  Software  Install  CD  for  LINUX”  into  the  CDROM  drive. 
Make  a  mount  point  for  the  cdrom.  i.e.  rnkdir  /mnt/cdrom.  Mount  the  cdrom  i.e.  mount 
/dev/hdc  /mnt/cdrom 

3.  Open  a  console  window  and  type  “tar  -xvf  /mnt/cdrom/RH8_Setup.tar”  and  then  press 
Enter. 

4.  Type  “cd  RH8”  and  press  Enter. 

5.  Type  “tcsh  configure_system.csh” 

6.  Follow  the  on-screen  instructions.  This  installation  will  take  over  10  minutes  to  complete. 
The  installation  will  install  PVM,  openal,  fltk,  fluid,  the  RTI  and  OpenGL  Performer  with 
a  demo  license..  Note  that  it  is  assumed  that  LINUX  has  already  been  installed.  Refer  to 
Section  Compilation/Build  Environment  On  LINUX  for  information  on  Compile/Build 
Environment  on  LINUX. 

7.  Unmount  the  cdrom  “umount  /mnt/cdrom”  and  insert  the  “HelMET  Operational  Software 
Install  CD”.  Mount  this  CD  as  above. 

8.  logout. 

9.  Log  in  as  vrsim  with  password  being  sea  king. 
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10.  Open  a  console  window  and  type  “tar  -zxvf  /mnt/cdrom/hdls.tgz”  and  then  press  Enter. 


4.3. 2. 2. 2  Compiling/Building  Source  Code  on  LINUX 

The  following  sections  describe  compiling/building  source  code  on  LINUX.. 

4.3.2.2.2.1  Cleaning  All  Executables  and  Object  Files 

The  procedure  for  cleaning  all  executables  and  object  files  is  described  below: 

1 .  Log  in  as  vrsim  with  password  being  seaking. 

2.  Open  a  console  window  and  type  “build  clean”. 

4.3.2.2.2.2  Cleaning  the  Entire  smart  Directory 

The  procedure  for  cleaning  the  entire  smart  directory  is  described  below: 

1 .  Log  in  as  vrsim  with  password  being  sea  king. 

2.  Open  a  console  window  and  type  “cd  local”. 

3.  Then  switch  to  a  directory  that  you  want  to  clean  by  typing  “cd  smart/src”. 

4.  Finally  type  “make  clean”. 

5.  “type  cd 

6.  Repeat  steps  3  through  5  for  the  rhs/src  and  savdb/src  directories. 

4.3.2.2.2.3  Cleaning  Specific  Subdirectories  Inside  smart  directory 

The  procedure  for  cleaning  specific  subdirectories  inside  hdls,  smart,  or  savdb  directories  is 
described  below: 

1 .  Log  in  as  vrsim  with  password  being  sea  king. 
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2.  Open  a  console  window  and  type  “cd  local”. 

3.  Then  switch  to  a  directory  that  you  want  to  clean.  For  example,  to  clean  the 
executables  and  object  files  located  in  -/ 1  o  c  a  I /s  m  art/s  rc/Pcrfo  rm  c  r, 
smart/src/Performer” . 

4.  Finally  type  “make  clean”. 


4.3.2.2.2.4  Full  Build 

The  procedure  for  performing  a  full  build  is  described  below: 


1 .  Log  in  as  vrsim  with  password  being  seaking. 

2.  Then  type  “build  all”. 


4.3.2.2.2.5  Building  the  Entire  smart  Directory 

The  procedure  for  building  the  entire  smart  directory  is  described  below: 

1 .  Log  in  as  vrsim  with  password  being  sea  king. 

2.  Open  a  console  window  and  type  “cd  local”. 

3.  Then  switch  to  a  directory  that  you  want  to  build  by  typing  “cd  smart/src”. 

4.  Finally  type  “make”. 


4.3.2.2.2.6  Building  a  Specific  Subdirectory 

The  procedure  for  building  a  specific  subdirectory  inside  the  smart  directory: 


1 .  Log  in  as  vrsim  with  password  being  sea  king. 

2.  Open  a  console  window  and  type  “cd  locaFsmart/src”. 


Performer 
type  “cd 
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3.  Then  switch  to  a  directory  that  you  want  to  build.  For  example,  to  build  the  CerealBox 
source  code  located  in  ~/local/smart/src/CerealBox,  type  “cd  CerealBox”. 

4.  Finally  type  “make”. 


4.4  Modification  Procedures 

The  following  sections  describe  the  modification  environment  and  process  for  the  FlelMET 
Operational  Software  CSC1. 


4.4.1  Modification  Environment 

4.4.1. 1  Modification  Environment  On  LINUX 

The  version  of  FlelMET  Operational  Software  CSC1  requires  the  following  system  environment: 


Flardware  Environment  - 

Refer 

LINUX 

Software  Environment  - 

Refer 

LINUX 

to  Section  Compilation/Build 
to  Section  Compilation/Build 


Environment 


Environment 


On 

On 


4.4.2  Modification  Process 


4.4.2. 1  Modification  Process  on  Linux 


4.4.2. 1.1  Graphic  User  Interface  Modification 

The  simulator  Graphic  User  Interface  (GUI)  is  developed  using  the  Fast  Light  Tool  Kit  (FLTK) 
Version  1.0.11.  The  FLTK  is  a  Free  Distribution  Software  package.  The  source  code  of  GUI  is 
created  using  the  Fast  Light  User  Interface  Designer  (FLUID)  graphical  editor.  FLUID  edits  and 
saves  its  state  in  .fl  files.  These  files  are  in  text  file  format,  which  can  be  edited  with  care  with  a 
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text  editor.  However,  the  most  efficient  and  safest  way  to  edit  the  .fl  files  is  to  use  the  FLUID 
graphical  editor. 


The  following  steps  describe  how  to  edit  a  FLUID  .fl  file: 

1.  Type  “fluid  <filename>.fl” 

e.g.:  fluid  DLPEditorWindow.fi 

2.  A  FLUID  graphical  editor  is  opened  with  the  file  DLPEditorWindow.fi  loaded. 

3.  The  user  can  now  edit  or  create  widgets.  Further  information  on  using  FLTK  can  be  found  in 
the  FLTK1.0.1 1  Programming  Manual  [Reference  n]. 

4.  Once  the  edition  is  completed,  the  user  can  save  the  changes  and  close  the  FLUID  editor. 

The  following  steps  describe  how  to  compile  a  FLUID  .fl  file: 


1 .  Type  “fluid  -c  <filename>.fl” 

e.g.:  fluid  -c  DLPEditorWindow.fi 

2.  The  FLUID  “compiler”  is  called  to  read  the  DLPEditorWindow.fi  and  write  the 
DLPEditorWindow.hpp  and  DLPEditorWindow.cpp  files.  If  there  are  any  errors  reading  or 
writing  the  files,  it  will  print  the  error  and  exit  with  a  non-zero  code. 


Once  the  .hpp  and  .cpp  files  have  been  updated/created,  the  source  code  can  be  compiled.  The 
GUI  library  can  then  be  built  by  invoking  the  “make”  command  in  the  GUI  directory. 


The  “make”  command  will  also  automatically  generate  the  .cpp  and  .hpp  files  when  it  detects  that 
the  .fl  file  has  a  date  newer  than  .cpp  and  .hpp  files 
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4.4.2. 1.2  MatrixX  Sea  King  Aerodynamic  Model  Modification 

The  MatrixX  6.2.2  from  MathWorks  Inc.  is  a  suite  of  development  tools  for  modelling  Sea  King 
aerodynamics.  To  create  a  Sea  King  helicopter  aerodynamic  model  with  clearly  delineated 
modules,  the  physical  model  must  be  implemented  using  the  MatrixX  software  package.  The 
package  is  designed  for  simulating  dynamic  system  and  can  auto-generate  C  code  for  use  in  a 
real-time  man-in-the-loop  helicopter  simulation. 


The  current  Sea  King  simulation  model  has  been  developed  by  the  University  of  Toronto  Institute 
of  Aerospace  Studies  (UTIAS)  and  implemented  in  MatrixX  using  its  SysemBuild  software.  The 
Sea  King  model  C-code,  which  is  generated  using  MatrixX’ s  AutoCode  feature,  is  integrated  into 
simulator  C++  code  for  use  in  a  real  time  environment. 


Further  information  on  basic  functions  of  MatrixX  and  simple  model  manipulation  can  be  found 
in  Appendix  C  “MatrixX  Notes  -  Sea  King  Simulator”.  These  notes  are  designed  to  serve  as  an 
introduction  to  users  who  would  use  the  MatrixX  to  modify  the  Sea  King  Simulator. 


NOTE 

Since  the  MatrixX  -  Sea  King  Aerodynamics  Model,  the  core  of  the  simulator,  is  a  piece  of 
complex  software,  it  must  be  emphasized  that  only  a  person  with  an  in-depth  knowledge  of 
aerodynamics  and  the  MatrixX  software  package  is  allowed  to  perform  the  modification  or 
enhancement  of  the  Sea  King  Aerodynamics  Model  code. 


4.4.2. 1.3  Visual  Modelling  Modification 

The  MultiGen  Creator  from  MultiGen  Paradigm  is  a  software  toolset  for  creating  a  highly 
optimized,  high-fidelity,  real-time  3D  database  for  use  in  visual  simulation.  There  are  two  visual 
models  in  the  simulator,  the  CPF  and  the  Sea  King  helicopter.  Both  of  these  3D  objects  are 
modelled  using  MultiGen  Creator. 


Information  on  maintaining  and  upgrading  the  simulator  visual  models  can  be  found  in  Appendix 
D  “Modifications  of  Simulator  Visual  Models”.  These  notes  are  designed  to  serve  as  an 
introduction  to  users  who  would  use  MultiGen  Creator  to  maintain  and  upgrade  the  simulator 
visual  models. 
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NOTE 


Since  the  maintenance  of  the  simulator  visual  models,  the  CPF  and  the  Sea  King  helicopter,  is  not 
a  trivial  task  to  perform,  it  must  be  emphasized  that  only  a  person  with  knowledge  of  using 
MultiGen  Creator  and  the  concept  of  a  visual  database  is  allowed  to  perform  the  modification  or 
enhancement  of  the  simulator  visual  models. 


4.4.2. 1.4  FREDYN  Ship  Dynamics  Modification 

FREDYN  is  a  software  package  used  for  the  ship  dynamics  within  the  simulator.  Developed,  in 
part  by  the  Maritime  Research  Institute  Netherlands  (MARIN),  and  supported  locally  by  DRDC- 
Atlantic,  the  FREDYN  software  library  is  written  in  Fortran.  The  version  of  the  library  that  is 
used  in  the  simulator  is  a  modified  implementation  of  the  version  6.0. 


FREDYN  interacts  with  other  helper  utilities  such  as  FRE1NP,  which  generates  required  data 
files.  Before  being  able  to  generate  ship  motion,  FREDYN  requires  a  number  of  different  data 
files  such  as  a  file  that  describes  the  ship  geometry. 


There  are  two  aspects  to  the  FREDYN  library.  First  there  is  the  actual  Fortran  code  base  that 
performs  the  dynamic  modelling  of  the  ship  within  a  dynamic  environment.  Secondly  there  is  an 
interface,  written  in  C++,  that  facilitates  real-time  integration  of  the  software  library  into  other 
applications,  such  as  the  simulator. 


Compilation  is  done  with  the  SGI  MIPSpro  F77  Fortran  compiler.  The  invocation  of  the 
compiler  is  through  the  standard  “make”  process.  To  compile  changes  to  the  FREDYN  library 
into  other  applications,  it  is  required  to  first  generate  a  static  library.  This  is  done  by  generating 
the  necessary  object  files  using  an  F77  Fortran  compiler  in  addition  to  compiling  the  C  interface 
code.  These  objects  can  then  be  linked  together  to  form  a  static  library  in  the  same  way  as  the 
rest  of  the  code  in  the  simulator.  A  higher-level  interface  to  the  FREDYN  code  is  provided  in 
ShipDynamics  class.  This  facilitates  the  encapsulation  of  the  FREDYN  library  within  a  higher 
level  construct. 


NOTE 

Modifying  the  FREDYN  library  should  be  limited  to  critical  bug  fixes  because  of  the  complexity 
of  the  software. 
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4.4.2. 1.5  C++  Source  Code  Modification 


The  simulator  Operational  Software  CSC1  is  designed  using  an  Object  Oriented  Design  approach 
and  its  source  code  is  implemented  using  the  C++  programming  language.  Throughout  the 
coding  phase  of  the  simulator  development  life  cycle,  certain  coding  guidelines  such  as  naming 
conventions  have  been  adopted.  The  coding  guidelines  that  are  used  in  this  simulator  project  are 
documented  in  the  DRDC  Toronto  document  “Developing  Maintainable  Code”  [Reference  f]. 


When  modifying  the  simulator  C++  code,  care  should  be  taken  to  follow  the  coding  guidelines 
that  have  been  followed  in  this  project.  By  doing  so,  the  source  code  can  be  sustainable  as  well  as 
reusable. 


Changes  to  the  source  code  can  be  performed  using  any  text  editor.  However,  it  is  recommended 
that  a  screen-based  editor  vi  editor  be  used,  as  it  is  very  common  in  the  Unix  world  and  also  it 
provides  power  features  to  aid  programmers. 


Once  the  changes  have  been  completed  and  saved,  they  can  be  compiled  /  built  using  the 
procedures  described  in  Section  Compilation/Build  Procedures. 


4.5  Creating  Installation  CD  Procedures 

4.5.1  Creating  Installation  CD  for  LINUX 

The  following  steps  must  be  performed  to  create  an  installation  CD  for  HelMET  Operational 
Software  CSC1  on  a  LINUX  environment: 


1 .  Log  in  as  vrsim  with  password  being  sea  king. 

2.  Copy  the  contents  of  the  previous  HelMET  Operational  Software  CSCI  Install  CD  for 
LINUX  to  a  temporary  directory  tmp  linux  on  the  LINUX  development  computer. 

3.  Verify  that  the  “local”  Directory  contains  the  source  code  that  a  CD  is  to  be  created. 
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4.  Type  “tar  -zcf  hdls.tgz  local” 

5.  Copy  the  zipped  files  hdls.tgz  to  the  temporary  directory  tmplinux. 

6.  Bum  the  contents  of  the  directory  tmplinux  onto  a  new  blank  CD. 

7.  Test  the  newly  created  CD,  using  the  procedures  described  in  the  Helicopter  Maritime 
Environment  Trainer  Operational  Software  CSC1  Version  Description  Document  [Reference 

i] 

4.6  Computer  Hardware  Resource  Utilization 

Not  applicable. 


4.7  Possible  Problems  and  Known  Errors 

Information  on  the  possible  problems  and  known  errors  is  described  in  the  Helicopter  Maritime 
Environment  Trainer  Operational  Software  CSC1  Version  Description  Document  [Reference  k]. 
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5  Notes 


5.1  Abbreviations  and  Acronyms 


Item 

Descriptions 

API 

Application  Programming  Interface 

CD 

Compact  Disk 

CD-ROM 

Compact  Disk  Read  Only  Memory 

CF 

Canadian  Forces 

CFB 

Canadian  Forces  Base 

COTS 

Commercial  Off  The  Shelf □ 

CPF 

Canadian  Patrol  Frigate 

CPU 

Central  Processing  Unit 

CSC 

Computer  Software  Component 

CSC1 

Computer  Software  Configuration  Item 

Dias 

The  operator  or  person  controlling  the  VR  Simulator 

DMSO 

Defence  Modelling  Simulation  Organization 

DOF 

Degrees  of  Freedom 
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DOS 

Disk  Operating  System 

DRAM 

Dynamic  Random  Access  Memory 

DRDC 

Defence  R&D  Canada 

FLTK 

Fast  Light  Tool  Kit 

FLUID 

Fast  Light  User  Interface  Designer 

FOV 

Field  of  View 

FTP 

File  Transfer  Protocol 

GB 

Gigabytes 

GUI 

Graphical  User  Interface 

HDLS 

Helicopter  Deck  Landing  Simulator 

HelMET 

Helicopter  Maritime  Environment  Trainer 

HLA 

High  Level  Architecture 

HMD 

Head  Mounted  Display 

HUD 

Head  Up  Display 

IBM 

International  Business  Machines 
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10S 

Instructor  Operator  Station 

KB 

Kilobytes 

LAN 

Local  Area  Network 

LOD 

Level  of  Detail 

MARIN 

Maritime  Research  Institute  Netherlands 

MB 

Megabytes 

MHz 

Mega  Hertz 

MS-DOS 

Microsoft  Disk  Operating  System 

NIM 

Network  Interface  Module 

N/A 

Not  Applicable 

NIC 

Network  Interface  Card 

OS 

Operating  System 

PC 

Personal  Computer 
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PVM 

Parallel  Virtual  Machine 

RAM 

Random  Access  Memory 

RGB 

Red  Green  Blue 

RHS 

Reconfigurable  helicopter  Simulator 

RPM 

Rotation  Per  Minute 

RT1 

Run  Time  Infrastructure 

SA1C 

Science  Application  International  Coiporation 

SBC 

Single  Board  Computer 

SGI 

Silicon  Graphics  Inc. 

SMART 

Simulation  Modeling  Acquisition  Rehearsal  Training 

SPS 

Software  Product  Specification 

SW 

Software 

TCP 

Transmission  Control  Protocol 

UCL 

University  College  London 

UTLAS 

University  of  Toronto  Institute  of  Aerospace  Studies 
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UPS 


Uninterruptible  Power  Source 


VGA 

Video  Graphics  Adapter 

VLP 

Virtual  Lesson  Plan 

VR-Sim 

Virtual  Reconfigurable  Simulator 
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Annex  A  Simulator  Software  Directory  Structure 


A.1  Simulator  Software  Directory  Structure 

Directories  marked  with  (dyn)  are  dynamically  created  in  some  automatic  or  semi-automatic  way. 
They  may  or  may  not  exist  or  have  any  appreciable  content. 
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Level  Level  1  Level  2 
0 


Level  3 


Level  4 


Level  5 


Level  6 


local/  config/  shearwater/ 
rhs/  bin/ 
docs/ 
hdls/ 


include/ 

lib/ 

mods/ 

scripts/ 

src/ 


Linux/ 
html/  (dyn) 
config/ 

shearwater/ 

DRDC/ 

config/ 

icons/ 

logs/ 

missionplans/ 

profiles/ 

resources/ 

tmp/ 

icons/  (N/A) 
logs/ 

flyco/ 

helo/ 

ios/ 

Iso 

mission_plans/ 

profiles/ 

scripts/ 

tmp/ 

vlp/ 

Linux/ 

Linux/ 

Apps/ 

HDLS 

deps/  (dyn) 
DRDC/ 


apps.mk 

Entities/  BaseEntity/ 

Bridge/ 

CPF/ 

DeckCrew/ 

FLYCO/ 

LandEnv/ 

LSO/ 

NFC/ 

Pilot/ 

Referee/ 

SeaEnv/ 

SeaKing/ 

SeaKingNFC/ 

TerrainEnv/ 

GUI/  AppsGUI/  DRDCHelo/ 

HDLS 


deps/  (dyn) 
objs/  (dyn) 
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Level  Level  1 

0 

Level  2 

Level  3 

Level  4 

Level  5 

Level  6 

BaseGUI/ 

images/ 

BaseLargeGUI/ 

DeviceGUI/ 

EntityGUI/ 

include/ 

images/ 

OptionsGUI/ 

ScenarioGUI/ 

DLPScenario 

images/ 

HAMScenario 

images/ 

mains.mk 

Makefile 

RHS-Core/ 

Base-Entities/ 

Environment/ 

Observer/ 

Scenario/ 

GUI-Core/ 

include/ 

Kernel/ 

Streams/ 

Clients/ 

Profiles/ 

Sources/ 

Utils/ 

Views/ 

Scenarios/ 

DLPScenario/ 

HAMScenario/ 

Utils/ 

smart/ 

bin/ 

Linux/ 

data/ 

CPF/ 

docs/ 

html/ 

include/ 

lib/ 

scripts/ 

src/ 

Apps/ 

CerealBoxGUI/ 

Fredyn/ 

CDAWSP/ 

CPF/ 

FREAN/ 

FREINP/ 

RUN/ 

HDLReader/ 

LineViewer/ 

LogAnalysis/ 

PerfViewer/ 

PlatformGUI/ 

SceneMaker/ 

SMDGenerator/ 

TrackerGUI/ 

TrackerTools 
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Level  Level  1  Level  2 
0 


Level  3 


Level  4 


Level  5 


Level  6 


savdb/ 


Audio/ 

AudioComm/ 

CerealBox/ 

lv3/ 

DataTree/ 

Debug/ 

Dynamics/ 

Helo/ 

GenHel 

MatrixX 

Sea/ 

Ship/ 

fredyn/ 

CDAWSP/ 

CPF/ 

FREAN/ 

FREDYN/ 

FREINP/ 

RUN/ 

ShipMo3D/ 

SampleData/ 

SampleLogs/ 

FilelO/ 

Filters/ 

IPME/ 

NIM/ 

PVM/ 

Performer/ 

Kalman/ 

Platform/ 

MotionBase/ 

PlatformServer/ 

Record/ 

SerialPort/ 

SmartFltk/ 

Socket/ 

Thread/ 

Tracker/ 

Utils/ 

MotionBase/ 

data/ 

CPF/ 

docs/ 

include/ 

html/ 

lib/ 

Linux/ 

models/ 

ADS33/ 

src/ 

textures/ 

CPF/ 

src/ 

textures/ 

DeckCrew/ 

hdls 

src/ 

Ocean/ 

src/ 

textures/ 

SeaKing 

adf/ 
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Level  Level  1  Level  2 
0 


Level  3 


Level  4 


Level  5 


Level  6 


conflg/ 


Sky/ 

scripts/ 

sounds/  HLPAudio/ 
VLPAudio/ 
src/ 

shearwater/ 


src/ 

textures/ 

src/ 
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Annex  B  SMART  Makefile  Structure 


B.1  SMART  Makefile  Structure 

This  document  provides  a  brief  overview  of  the  SMARTMakefile  structure. 


SMART  Makefiles 


The  following  makefiles  provide  common  rules  and  variable  declarations  for  building  SMART 
libraries. 


Makefile 

Description 

SMART  defs.mk 

variable  declarations  common  to  all  makefiles 

SMART  defsLinux.mk 

variable  declarations  specific  to  Linux 

SMART  deps.mk 

includes  a  *.d  dependency  file  for  every  *.o  object  file, 
and  specifies  rules  for  building  *.d  dependency  files 

SMART  libs.mk 

variable  declarations  for  library  names  and  locations 

SMART  rules. mk 

common  rules  for  building  .o  files 

SMART  sources.mk 

common  rules  for  building  .cpp  and  .hpp  source  files 

SMART  makedirs.mk 

rule  for  recursing  through  and  building  subdirectories 

SMART  maketargets.mk 

rule  for  calling  a  series  of  specified  makefiles  within 
a  directory 

SMART  makebin.mk 

rule  for  building  an  target  executable 

SMART  makebindefs.mk 

includes  defs  required  for  building  an  executable 

SMART  makelib.mk 

obsolete  -  use  SMART  makestaticlib.mk  or 

SMART  makedynamiclib.mk 

SMART  makelibdefs.mk 

includes  defs  required  for  building  a  library 

SMART  makestaticlib.mk: 

rule  for  building  a  target  static  library  (archive) 

SMART  makedynamiclib.mk 

rule  for  building  a  target  dynamic  library  (shared  object) 

SMART  makemod.mk 

rule  for  building  a  mod  (object  files)  defined  in  the  OBJS 
environment  variable. 

SMART  makemoddefs.mk 

includes  defs  required  for  building  a  mod 
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B.2  Definitions  of  mods,  bins,  libs  and  ii_files 

mods,  bins,  libs  and  ii  files  are  the  four  types  of  targets  supported  by  the  SMART  makefiles. 


lib: 

A  collection  of  object  files  bound  together  into  a  single  file.  A  lib  can  be  either  a  static  archive 
(.a)  or  a  dynamic  shared  object  (.so). 


bin: 

An  executable  program. 


mod: 

A  collection  or  grouping  of  object  files,  mods  are  useful  in  separating  different  components  of  a 
project  without  having  to  resort  to  libraries.  Project  A  may  use  mod  X  and  Y,  while  Project  B  can 
use  mod  Y  and  Z. 


iifiles 

The  ii  files  directory  contains  .ii  files  which  are  automatically  generated  by  the  compiler,  one  for 
each  source  file.  These  .ii  files  help  the  prelinker  determine  which  files  are  responsible  for 
instantiating  the  various  template  entities  referenced  in  a  set  of  object  files. 


B.3  Dependency  Definition 

There  is  a  dependency  between  A  and  B  when  A  includes  B.  If  B  is  changed,  A  must  be 
recompiled.  An  intelligent  makefile  will  check  B  when  determining  whether  or  not  to  compile  A. 


For  each  object  (.0)  file  compiled  in  SMART,  there  is  a  corresponding  dependency  (.d)  file  listing 
all  of  the  other  files  on  which  that  object  file  depends.  The  list  is  in  the  form  of  a  Makefile  rule. 
Once  the  file  is  generated,  its  rule  is  included  into  the  current  make  session. 
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An  object  file  will  typically  depend  on  a  series  of  header  (.hpp)  files.  A  target  will  depend  on  its 
list  of  object  files,  and  any  static  libraries  it  is  linking  with. 


B.4  Tracking  Includes 

The  following  makefiles  with  proper  indentation  illustrate  the  makefile  includes  dependencies. 
For  an  example,  the  SMARTmakebindefs.mk  file  includes  SMARTdefs.mk  and 
SMART  libs.mk.  The  SMART  defs.mk  includes  SMART  defsLinux.mk. 


SMARTmakedirs.mk 

SMARTmaketargets.mk 

SMARTmakebindefs.mk 

-  SMART  defs.mk 

-  SMARTdefsLinux.mk 

-  SMARTlibs.mk 

SMARTmakebin.mk 

-  SMARTsources.mk 

-  SMARTdeps.mk 

-  SMARTrules.mk 

SMART  makelibdefs.mk  or  SMART  makestaticlib.mk  or  SMART  makedynamiclib.mk 

-  SMART  defs.mk 

-  SMART  defsLinux.mk 

-  SMART  libs.mk 

SM  ARTmakelib .  mk 

-  SMART  sources.mk 

-  SMART  deps.mk 

-  SMART  rules.mk 

SMARTmakemoddefs.mk 

-  SMART  defs.mk 

-  SMART  defsLinux.mk 

-  SMART  libs.mk 

SMARTmakemod.mk 

-  SMART  sources.mk 

-  SMART  deps.mk 

-  SMART  rules.mk 
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B.5  Example  Makefiles 


In  general,  several  variables  must  be  defined,  and  then  the  appropriate  .mk  files  included.  The 
exact  variables  and  .mk  files  depends  on  the  nature  of  the  target  being  compiled  (dir,  lib,  mod, 
bin). 


An  example  makefile  for  building  a  binary  is  included  below: 


# 

#  Name  of  stub  binary 

# 

TARGET  =  $(RHS_BIN_DIR)/ dummymain 

# 

#  Common  variables,  rules,  and  libs  used  by  the  target 

# 

include  $(RHS_INCLUDE_DIR)/RHS_makebindefs.mk 
# 

#  Define  the  objects,  modules,  and  libraries  used  by  the  binary 

# 

OBJS  =  $(OBJS_DlR)/dummy_main.o 

STAT1C  LIBS  =  $(SMART_LIBS)  \ 

$( SMART  THREAD  LIB  S)  \ 

-lMyOtherStaticLib 

DYNAMICLIBS  =  -lOneOfMyDynamicLibs 


MODS  =  $(COMMON_MOD)  \ 
$(ENT1TYDB_M0D)  \ 
$(S0L0_SESS10N_MANAGER_M0D)  \ 
$(CONTROL_MOD)  \ 
$(DUMMY_FEDERATE_MOD)  \ 
$(DUMMY_MODEL_MOD)  \ 
$(DUMMY_SCENAR10_M0DEL_M0D)  \ 
$(DUMMY_SOURCE_MOD)  \ 
$(DUMMY_CL1ENT_M0D)  \ 
$(DUMMY_VIEW_MOD)  \ 
$(DUMMY_PROFILE_MOD)  \ 
$(DUMMY_COMMON_ENGINE_MOD)  \ 
$(DUMMY_LOCAL_ENGlNE_MOD)  \ 
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$(DUMMY_SCENARIO_COMMON_ENGINE_MOD)\ 

$(DUMMY_SCENARIO_LOCAL_ENGINE_MOD) 


# 


#  Include  the  specific  rules  for  making  a  binary  target 

# 

include  $(RHS_INCLUDE_DIR)/RHS_makebin.mk 


An  example  makefile  for  a  building  a  mod  is  included  below: 


# 

#  Name  of  mod  -  this  variable  isn't  used 

# 

TARGET  =  mymod 

# 

#  Common  variables,  rules,  and  libs  used  by  the  target 

# 

include  $(RHS_INCLUDE_DIR)/RHS_makemoddefs.mk 
# 

#  The  list  of  object  files  for  this  mod... 

# 

OBJS  =  $(OBJS_DlR)/Foo.o  \ 
$(OBJS_DlR)/SuperDuper.o  \ 

$(OB  J  S_DlR)/Bopper.  o 

# 


#  Include  the  specific  rules  for  making  a  module 

# 

include  $(RHS_INCLUDE_DlR)/RHS_makemod.mk 


An  example  makefile  for  a  building  a  mod  is  included  below: 
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# 

#  Name  of  library 

# 

TARGET  =  $(  SM  ART_LIB_DIR)/lib  SM  ARTUtils .  a 

# 

#  Common  variables,  rules,  and  libs  used  by  the  target 

# 

include  $(SMART_INCLUDE_DIR)/SMART_makelibdefs.mk 
# 

#  The  list  of  object  fdes  for  this  library... 

# 

OBJS  =  $(  OBJ  SDIR)/ C  oord.  o  \ 

$(  OBJ  S_D1R)/V  ector.o  \ 

$(OBJ S_DlR)/Math.o  \ 

$(OBJ  S_DlR)/Semaphore.o 

# 


#  Include  the  specific  rules  for  making  a  static  library 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_makestaticlib.mk 


B.6  List  of  SMART  Make  Files 


B.6.1  SMART  defs.mk 


#!gmake  -j 

############################################# 

# 

#  Common  Makefile  include  for  all  SMART  makefiles 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 
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#  Zamke,  Micah 

# 

#  Adapted  from  a  similar  include  file  built  with  input  from  Nelson  Ho 

# 

############################################# 

######  COMMON  SMART  LOCATIONS  ###### 

#SMART_LIB_DIR  =  $(SMART_HOME)/lib 
#SMART_B1N_D1R  =  $(SMART_HOME)/bin 
#SMART_1N  CLUDEDIR  =  $(  SMART_HOME)/include 
SMARTCONFIGDIR  =  $(SMART_HOME)/config 
SM  ARTMODEL  SDIR  =  $(SMART_HOME)/models 

SM  ARTN  ET  W  ORKD1R  =  $(  SM  ART_HOME)/N  etwork 
SMARTHARDWARED1R  =  $(SMART_HOME)/Hardware 

PVM1NCLUDED1R  =  $(PVM_ROOT)/include 

######  COMMON  SMART  INCLUDES  ###### 

COMMON1NCLUDES  =  -1/opt/include/elumens 

SM  ART1N  CLUDE  S  =  -1$(SMART_1NCLUDE_D1R)  $(L0CAL_1NCLUDES) 

$(COMMON_lNCLUDES)  \ 

-1$(RT1_1NCLUDE_H0ME)  -1$(PVM_INCLUDE_D1R) 

PROJ1NCLUDES  +=  $(SMART_1NCLUDES) 

######  COMPILER  SPECIFIC  OPTIONS  ###### 

PROJOPTIMIZE  =  -03 
PROJWARNINGS 
#CDEBUG  =  -g3  -DDEBUG 

#CXXDEBUG  =  -g3  -DDEBUG 

#F77DEBUG  =  -DDEBUG 

######  PLATFORM  SPECIFIC  DEFINES  ###### 

# 

#  Filename  Macros 

# 

OBJ  =  .0 
LIBPRE  =  lib 
LIBPOST  =  .a 
EXE= 


# 

#  Base  Utilities 


54 


DRDC  Toronto  TM  2011-050 


# 

CC 

=  CC 

cxx 

=  CC 

F77 

=  f77 

LD 

=  Id 

MAKESTATICLIB  =  $(CXX)  -ar  -o 
MAKEDYNAMICLIB  =  $(CXX)  -shared 

#  This  was  changed  after  a  gee  compiler  upgrade  from  2.95  to  3.0.4  on  the 

#  SGI  machines.  With  the  change  in  versions,  the  location  of  the  hash  map 

#  include  changed  messing  up  the  generation  of  dependencies.  It  is  better 

#  if  we  can  use  gee  -MM  to  generate  dependencies  because  it  excludes  system 

#  header  files,  but  becase  gee  now  has  <hash_map>  in  a  different  place  than 

#  CC,  we  will  have  to  use  the  same  compiler  to  generate  the  dependancies  that 

#  we  use  for  actual  compiling  (for  IRIX  and  1R1X64  this  means  CC). 

#MAKEDEP  =  gee  -MM 

MAKEDEP  =  $(CXX)  -M 

M AKEDEP  F7 7  =  f77  -M 

MAKED1R  =  rnkdir 

RANL1B  =  ar  -s 
AS  =  as 

FLUID  =  fluid 

ARCH  =  $(  SMARTARCH) 

# 

#  Shell  Commands 

# 

RM  =  rm  -f 
CP  =  cp  -f 
MV  =  mv  -f 
MKD1R  =  rnkdir  -p 

include  $(SMART_lNCLUDE_DlR)/SMART_defs$(ARCH).mk 

# 

#  Compiler  flags 

FLAGS  +=$(PR0J_1NCLUDES)  $(PR0J_WARN1NGS)  $(PR0J_0PT1M1ZE) 
CFLAGS  +=$(FLAGS)  ${CDEBUG} 

CXXFLAGS  +=$(FLAGS)  ${CXXDEBUG} 

F77FLAGS  +=$(FLAGS)  ${F77DEBUG} 

MAKEDEPFLAGS  +=$(FLAGS) 

MAKEL1BFLAGS  += 

LDFLAGS = 

ARFLAGS  = 

ASFLAGS  = 
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B.6.2  SMART  defsLinux.mk 


############################################# 

# 

#  Common  Makefile  include  dealing  with  Linux  specific  defines 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

#  Adapted  from  a  similar  include  file  built  with  input  from  Nelson  Ho 

# 

############################################# 


#  Base  Utilities 

# 

# ALLEN  AJIT  GEORGE 
CC  =  gcc-4.3 

CXX  =  g++-4.3 

F77  =  g77  -g2  -fmit-local-zero  -fno-automatic 

MAKESTATICLIB  =  ar -r 

MAKEDEP  =  $(CXX)  -MM 

MAKED1R  =  rnkdir 

SHELL  =  /bin/bash  -c 

FORTRANLIBS  =  -lg2c 

FLTK  LIBS  =  -L/usr/local/lib  -lfltk_v3  $(X1 1LIBS) 

X 1 1  LIBHOME  =  -L/usr/X  1 1  R6/lib 
MAKELIBFLAGS  = 

#CXXFLAGS  +=  -g2  -DDEBUG  -DPERF_VER_2_4  -ftemplate-depth-99  -Wall  \ 

# 

CXXFLAGS  +=  -DPERF_VER_2_4  -ftemplate-depth-99  -Wall  \ 

-DSMART  LE  BYTE  ORDER  -DREENTRANT  -DRTI  USES  STD  FSTREAM 

\ 

-DPO  SIXPTHREADSEMAN  TIC  S 
PROJWARNINGS  +=  -Wno-ctor-dtor-privacy 


B.6.3  SMART_deps.mk 


#!  gmake 
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################################# 

# 

#  SMART  Makefile 

# 

#  This  will  create  a  single  .d  file  for  every  .0  file  in  OBJS.  The  .d 

#  file  is  a  list  of  all  includes  for  the  given  object  and  is  included  as 

#  a  list  of  dependandcies  for  rebuilding  the  .0. 

# 

#  Required:  OBJS  -  list  of  object  files  for  which  the  dependancies  are  built 

#  OBJ S  D1R  -  location  of  object  files 

#  DEPSDIR  -  location  of  dependancy  files 

# 

#  Output:  DEPS  -  list  of  .d  files 

#  LIBDEPS  -  list  of  project  library  dependancies 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

# 

#  for  now  assume  anything  in  LIBS  is  static  (this  is  to  support  stubs  and 

#  things  created  before  we  cared  about  static  vs  dynamic) 

# 

STATICLIBS  +=  $(LIBS) 

# 

#  first  build  the  lib  dependancies  by  removing  all  nonlibs  from  the  list 

# 

LIB  DEPS  +=  $(filter  -1SMART%,  $(filter-out  -L%,  $(STATIC_LIBS))) 


#################  Dependacy  stuff  #################### 

# 

#  In  each  source  directory  there  is  a  ./deps  directory  containing  a  single 

#  .d  file  for  every  .0  file.  Each  .d  file  contains  a  list  of  dependancies 

#  for  both  the  .d  and  corresponding  .0.  The  compiler  will  check  those 

#  dependancies  to  determine  whether  or  not  to  rebuild  the  .d  or  .0. 

#  The  .d  is  built  using  the  implicit  rules  defined  below. 

# 

# 

#  If  DEPS  DIR  wasn't  set,  assign  a  default 

# 

ifeq  (,$(DEPS_DIR)) 
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DEPSDIR  =  deps/$(ARCH) 


endif 

# 

#  build  the  list  of  dependancy  files...  one  and  only  one  for  each  object  file 

# 

S1NGLE  OBJS  =  $(notdir  $(OBJS)) 

DEPS  =  $(addprefix  $(DEPS_DIR)/,$(SINGLE_OBJS:.o=.d)) 

# 

#  Include  the  dependancy  files  (sinclude  ignores  failures)  but  only  if  not 

#  building  'clean',  sinclude  will  attempt  to  make  any  target  files  it 

#  can't  find,  and  if  we're  cleaning  everything  out,  we  don't  want  to  waste 

#  time  first  building  things  up. 

# 

ifeq  (,$(fmdstring  clean, $(MAKECMDGOALS))) 
ifeq  (,$(fmdstring  cleanall,$(MAKECMDGOALS))) 
sinclude  $(DEPS) 
endif 
endif 


################  Dependancy  Rules  ##################### 

# 

#  The  .d  file  is  first  built  by  using  the  -M  compiler  option.  This 

#  does  a  search  through  the  .cpp  file  recording  all  of  the  non-system 

#  include  files.  The  search  is  recursive,  so  it  contains  names  of  files 

#  included  by  files  included  by  the  .cpp. 

# 

#  The  second  part  of  the  command  (sed)  takes  the  file  list  of  the  form: 

#  foo.o:  foo.cpp  foo.hpp  foobase.hpp  global.hpp 

# 

#  and  replaces  it  with  a  file  of  the  form: 

#  foo.o  deps/foo.d:  foo.cpp  foo.hpp  foobase.hpp  global.hpp 

# 

#  This  ensures  that  the  both  the  .0  and  the  .d  file  are  rebuilt  if  one 

#  of  the  dependancies  changes  (just  in  case  you  add  or  delete  an  #include). 

# 

#  These  DR  vars  are  a  clever  hack  to  allow  \s  in  the  sed  command 
DRDEPSDIR  =$(subst  /,V,$(DEPS_DIR)) 

DR  OBJS  DIR  =$(subst  /,V,$(OBJS_DIR)) 

# 

#  create  a  macro  command  for  creating  the  dependancy  files 

# 
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define  MAKEDEPS 

@$(SHELL)  'if  [  !  -d  $(DEPS_DIR)  ];  then\ 
echo  ;  \ 

echo  Creating  deps  directory  $(DEPS_DIR)  ;  \ 

$(MKDIR)  $(DEPS_DIR)  ;  \ 
fi' 

@echo;  \ 

echo  Making  dependancies  file:  $@ 

@$(MAKEDEP)  $(MAKEDEP_FLAGS)  $<  |  \ 

sed  'sA($*\)\.o[  :]*/$(DR_OBJS_DIR)V\l.o  $(DR_DEPS_D1R)V$(@F) :  /g'  >  $@; 
endef 


# 

#  Rules  for  making  the  dependancies 

# 

$(DEPS_DlR)/%.d:  %.cpp 
$(MAKE_DEPS) 


$(DEPS_DlR)/%.d:  %.cxx 
$(MAKE_DEPS) 

$(DEPS_DlR)/%.d:  %.C 
$(MAKE_DEPS) 

$(DEPS_DlR)/%.d:  %.c 
$(MAKE_DEPS) 

$(DEPS_DlR)/%.d:  %.F 
$(MAKE_DEPS) 


B.6.4  SMART  libs.mk 


#!gmake 

################################# 

# 

#  SMART  Makefile 

# 

#  Defines  variables  for  the  standard  system  libraries  and  all  smart 

#  libraries  provided  by  smart. 

# 

#  Copyright  (c)  1999,2000 

# 
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#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 


######  THIRD  PARTY  LIBS  ###### 

# 

#  Location  of  3rd  party  libraries  and  include  files 

#  When  compiling  on  new  systems  you  may  have  to  edit  the  location  or  names 

#  of  the  following  libraries 

# 

XI 1LIBS  =  $  {XI 1LIB  HOME}  -1X1 1  -lm 
AUDIO  LIBS  =  -lm  -laudio  -laudiofile 
OPENGLLIBS  =  -1GL  -1GLU 

OSG  LIBS  =  -losg  -losgDB  -losgViewer  -losgSim  -losgUtil  -losgFX  -losgBB3D  -lbbUtil3_0 
-lbbMath3_0  -lbbGFX3_0  -lbbDB3_0  -lbbCore3_0  -lbbEdit3_0  -lbbView3_0  -lbbBB3D3_0  - 
1GL  -1GLU  -lgdal  -lproj  -lfreeimage  -lXxf86vm  -ltinyxml  -IbnxLicenseClient  -lmgapilib  -lmgdd  - 
lpthread 

OPENALLIBS  = -lopenal 

THREAD  LIBS  =  -lpthread  -D  PTHREADS 

FLTK  LIB  S  =  -L/usr/local/lib  -lfltk  $(X  1 1  LIB  S) 

RAT  LIBS  =  -L/usr/local/lib  -luclmmbase 
PVM  LIBS  =  -LS  {PVM_ROOT}/lib/$  {PVM  ARCH}  -lpvm3 
SPI  LIBS  =  -L/opt/lib/elumens/N32  -lspiclops 
SHIPMOLIBS  = 

# 

#  The  -Wl,-rpath,$  {RTI  LIB  HOME}  builds  the  RTI  LIB  HOME  directory  directly 

#  into  the  executable's  search  path  for  shared  object  files  (*.so). 

#  This  is  necessary  to  support  the  use  of  capability  settings  on  IRIX.  If 

#  the  user  has  special  capability  settings  (i.e.  access  to  real-time 

#  schedualing),  then  their  LD  LIBRARY  PATH  is  disabled  for  security  reasons. 

#  Without  access  to  LD  LIBRARY  PATH,  the  executable  must  already  know  where 

#  to  find  libRTI-NG.so  or  it  will  fail  to  run. 

# 

#  This  is  only  an  issue  on  IRIX  and  if  using  SMART::  System:  :S_enableRealTime(). 

#  For  more  information,  see  'man  sched  setscheduler'  and  'man  capability' 

#  (on  IRIX). 

# 

RTI  LIBS  =  -L$  {RTI  LIB  HOME]  -lpthread  -1RTI-NG  -lfedtime  \ 

-Wl,-rpath,$  {RTILIBHOME} 


######  COMMON  SMART  LIBS  ###### 
SMARTLIBS  =  -L$(SMART_LIB_DIR) 
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SMART  UTILS  LIBS  =  -ISMARTUtils  -lm 

SM  ARTDEB  U  GLIB  S  =  -ISMARTDebug 

SMARTFILEIOLIBS  =  -ISMARTFilelO 

SMART  THREAD  LIBS  =  -ISMARTThread  $(THREAD_LIBS) 

SM  ARTCERE  ALB  OXLIB  S  =  -ISMARTCerealBox 
SMARTTRACKERLIBS  =  -ISMARTTracker 
SMARTPLATFORMLIBS  =  -ISMARTPlatform 
SMARTAUDIOLIB  S  =  -ISMARTAudio 
SMARTSOCKETLIBS  =  -ISMARTSocket 
SMARTDATATREELIBS  =  -ISMARTDataTree 
SM ART  F LTK  LIB S  =  -ISMARTFItk  $(FLTK_LIBS) 

SM  ARTSHIPD  YN AMIC SLIB S  =  -ISMARTShipDynamics  $(FORTRAN_LIBS) 
SMARTGENHELLIBS  =  -ISMARTGenHel 
SM  ARTSE  AD  YN  AMIC  SLIB  S  =  -ISMARTSeaDynamics 
SMART  OSG  LIBS  =  -ISMARTOSGDriver  $(OSG_LIBS) 

SMART  HDL  READER  LIB S  =  -lHDLReader 
SMART  RAT  LIBS  =  -1SMARTRAT  $(RAT_LIBS) 

SM  ARTAU  DIOCOMMLIB  S  =  -ISMARTAudioComm 

SMARTRECORDLIBS  =  -ISMARTRecord 

SMARTSEAK1NGLIBS  =  -ISMARTSeaKing 

SMARTMATR1XXLIBS  =  -ISMARTMatrixX 

SM  ARTJ  ETRAN  GERLIB  S  =  -ISMARTJetRanger 

SMARTEH101LIBS  =  -1SMARTEH101 

SMART  PVM  LIBS  =  -1SMARTPVM  $(PVM_LIBS) 

SMARTSERIALPORTLIBS  =  -ISMARTSerialPort 

SMARTIPMELIB  S  =  -1SMARTIPME 

SMARTASTILIBS  =  -1SMARTASTI 

SMART  SHIPMO  LIBS  =  -ISMARTShipMo  $(SHIPMO_LIBS) 

SMART  BASE  LIBS  =  $(SMART_LIBS)  \ 

$(SMART_FILEIO_LIBS)  \ 

$(SMART_THREAD_LIBS)  \ 

$(SMART_DEBUG_LIBS)  \ 

$(SMART_UTILS_LIBS)  \ 

$(X1 1LIBS) 

ifdef  REMOVENIM 
SMARTNIMLIBS 
else 

SMART  NIM  LIBS  =  -1SMARTN1M  $(RT1_LIBS) 
endif 


# 

#  The  VPATH  is  where  make  searches  for  dependancy  files  (i.e.  -ISMARTmylib) 

#  Note  when  it  finds  a  library  as  a  dependancy,  it  knows  to  expand  it  to 

#  it's  full  name  (i.e.  libSMARTmylib.a) 

# 

VPATH  +=  $(SMART_LIB_DIR) 
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B.6.5  SMART  rules. mk 


#!  gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  0BJS  D1R  -  location  of  object  files 

#  DEPSDIR  -  location  of  dependancy  files 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 

######  COMMON  RULES  AND  TARGETS  ###### 

# 

#  Rules 

# 

.SUFFIXES:  .0  .cpp  .c  .d  .F  .fl  .C  .cxx 

####  protect  the  targets  that  should  always  be  run  without  question 
.PFIONY  :  clean  cleanall  all 

# 

#  The  name  of  the  ii  files  for  the  specified  OBJS 

# 

II  FILES  =  $(addprefix  $(OBJS_DlR)/ii_files/,$(notdir  $(OBJS:.o=.ii))) 


#  Macro  for  the  conmiand  to  create  the  directory  for  object  files 

# 

define  MAKE  OB J  S  D1R 
@$(SHELL)  'if  [  !  -d  $(OB J S  D1R)  ];  then\ 
echo  ;  \ 

echo  Creating  object  directory  $(OBJS_DIR)  ;  \ 
$(MKDIR)  $(0BJS_D1R)  ;  \ 
fi' 

@echo; 

endef 
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# 

#  Standard  rules  for  building  .0  files.  The  objs  directory  must  be 

#  created  if  it  doesn't  already  exist. 

# 

$(  OBJ  S_DlR)/%.  0 :  %.c 

$(MAKE_OB  J  SDIR) 

$(CC)  $(CFLAGS)  -0  $@  -c  $*.c 

$(OB J  S_DlR)/%.  0 :  %.cpp 

$(MAKE_OB  J  SDIR) 

$(CXX)  $(CXXFLAGS)  -0  $@  -c  $*.cpp 


$(OB J  S_DlR)/%.  0 :  %.cxx 

$(MAKE_OB  J  SDIR) 

$(CXX)  $(CXXFLAGS)  -o  $@  -c  $*.cxx 

$(OB J S_DlR)/%. 0 :  %.C 

$(MAKE_OB  J  SDIR) 

$(CXX)  $(CXXFLAGS)  -0  $@  -c  $*.C 

$(OB J S_DlR)/%. 0 :  %.F 

$(MAKE_OB  J  SDIR) 

$(F77)  $(F77FLAGS)  -0  $@  -c  $*.F 


# 

#  Clean  .0  files,  .d  files,  and  all  targets 

# 

clean  cleanall: 

-$(RM)  $(OBJS) 

-$(RM)  $(11_F1LES) 

-$(RM)  $(DEPS) 

-$(RM)  $(TARGET) 

-$(RM)  stub 


B.6.6  SMART  sources. mk 


#!  gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required: 

# 

#  Copyright  (c)  1 999,  2000,  200 1 
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# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

######  COMMON  RULES  FOR  MAKING  SOURCE  FILES  ###### 


# 

#  Rules  for  building  .hpp  and  .cpp  files 

# 

%.hpp  %.cpp:  %.fl 
@echo; 

@echo  Building  gui  source  and  header  files 
$(FLUID)  -o  .cpp  -h  .hpp  -c  $A 

%.hpp: 

@echo;  \ 

echo  Ignoring  missing  file  $@ 


B.6.7  SMART  makedirs.mk 


#!  gmake 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  DIRS  -  List  of  subdirectories  to  be  built 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

# 

#  Loop  through  the  specified  DIRS  calling  make  in  each  with  the  same 

#  arguemnets  whith  which  this  makefile  level  was  called. 

# 

#  RK  Changed  the  'cd'  commands  to  go  back  to  the  original  working  directory 
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#  so  we  can  properly  handle  deep  children.  Also  added  test  to  see  if  directory 

#  exists 

CURRENTDIR  =  $(PWD) 

#  make  sure  default  is  the  first  one  here 
default  all  clean  cleanall: 

@for  DIR  in  $(DIRS);  do  \ 
if  [  -d  $$D1R  ] ;  then  \ 

echo  ;  echo  "/■ - $$D1R - ■/"  ;  echo  ;  \ 

cd  $$D1R;  \ 

$(MAKE)  $@;  \ 
cd  $(CURRENT_DIR);  \ 
fi\ 

done 

@echo  ;  echo 


B.6.8  SMART_maketargets.mk 

#!gmake 

#  note  the  lack  of  "-j"  above...  this  is  so  that  things  are  done 

#  one  at  a  time 

################################# 

# 

#  SMART  Makefile 

# 

#  This  will  loop  through  the  targets  and  stubs  calling  a  separate  makefile 

#  for  each.  The  name  of  each  makefile  is  taken  from  the  name  of  the 

#  target  or  stub  and  appanded  with  .mk.  Each  makefile  is  called  with  the 

#  same  arguments  with  which  this  level  of  Makefile  was  called. 

# 

#  Required:  TARGETS  -  list  of  normal  targets  to  build  by  default 

#  STUBS  -  list  of  stubs  to  build  with  the  'stubs'  target 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 

# 

#  Prefix  the  list  with  the  word  clean  and  cleanall...  this  will  later  be 

#  used  to  identify  which  arguement  to  give  to  the  makefiles 
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# 

CLEAN  =  $(addprefix  clean,  S(TARGETS)) 

CLEANALL  =  $(addprefix  cleanall,  $(TARGETS))  $(addprefix  cleanall,  $(STUBS)) 

# 

#  We  now  want  to  append  in  all  the  platform  specific  targets 

# 

TARGETS  :=  $(TARGETS)  $($(SMART_ARCH)_TARGETS) 

STUBS  :=  $(STUBS)  $($(SMART_ARCH)_STUBS) 

# 

#  Standard  make  arguements  should  apply  to  all  targets  and  stubs 

# 

default :  $(TARGETS) 
all :  $(TARGETS)  $(STUBS) 
stubs:  $( STUBS) 
clean:  $(CLEAN) 
cleanall:  $(CLEANALL) 

$(TARGETS)  $(STUBS): 

@echo;  \ 

echo  "  /--  $@  \ 

echo; 

@$(MAKE)  -f  $@.mk 

$(CLEAN): 

@echo;  \ 

echo  "  /—  $(subst  clean„$@)  clean  \ 

echo; 

@$(MAKE)  -f  $(subst  clean„$@).mk  clean  ; 

$(CLEANALL): 

@echo;  \ 

echo  "  /—  $(subst  cleanall„$@)  cleanall  \ 

echo; 

@$(MAKE)  -f  $(subst  cleanall„$@).mk  cleanall ; 


B.6.9  SMART  makebin.mk 


#!gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  TARGET  -  the  target  binary  name 
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#  OBJS  -  list  of  objects  in  the  binary 

#  SHARED  LIBS  -  list  of  static  (.a)  libraries  used  by  the  binary 

#  DYNAM1C  L1BS  -  list  of  dynamic  (.so)  libraries  used  by  the  binary 

#  MODS  -  list  of  modules  used  by  the  binary 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 

# 

#  Include  all  common  dependancies  and  rules  for  the  target 

# 

include  $(SMART_INCLUDE_DIR)/SMART_sources.mk 
include  $(SMART_INCLUDE_DIR)/SMART_deps.mk 
include  $(SMART_INCLUDE_DIR)/SMART_rules.mk 

# 

#  sort  and  prune  the  list  of  objects  and  mods  to  remove  duplicates 

# 

PRUNED  OBJS  =  $(sort  $(OBJS)) 

PRUNED  MODS  =  $(sort  $(MODS)) 

# 

#  include  both  static  and  shared  libs 

# 

ALL  L1BS  =  $(DYNAM1C_L1BS)  $(STAT1C_L1BS) 

# 

#  The  actual  rule  for  making  binaries 

# 

$(TARGET):  $(DEPS)  $(PRUNED_OBJS)  $(PRUNED_MODS)  $(L1B_DEPS) 

@$(SHELL)  'if  [  !  -d  $(@D)  ];  then\ 
echo  ;  \ 

echo  Creating  object  directory  $(@D) ;  \ 

$(MKD1R)  $(@D) ;  \ 
fi' 

@echo; 

$(CXX)  $(CXXFLAGS)  $(PRUNED_OBJS)  $(PRUNED_MODS)  $(ALL_L1BS)  -o  $@ 


B.6.10  SMART_makebindefs.mk 

################################# 
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# 

#  SMART  Makefile 

# 

#  Required:  TARGET  -  the  target  binary  name 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

# 

#  This  is  the  default  rule  (first  rule  encountered) 

# 

default  all:  $(TARGET) 

# 

#  Locations  used  by  included  makefiles 

# 

OBJ  SD1R  =  objs/$(ARCH) 

DEPSDIR  =  deps/$(ARCH) 

MODSD1R  = 

# 

#  Common  variables,  rules,  libraries,  and  dependancies 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_defs.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_libs.mk 


B.6.11  SMART  makelib.mk 


#!gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  OBSOLETE! ! ! ! !  -  please  use  SMART  makestaticlib  or  SMART  makedynamiclib 

# 

# 

#  Required:  TARGET  -  the  full  target  library  name 

#  OBJS  -  list  of  objects  in  the  library 
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#  MODS  -  list  of  modules  used  by  the  library 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 
include  $(SMART_INCLUDE_DIR)/SMART_makestaticlib.mk 
# 

#  Include  all  dependancies  and  rules  for  the  target 

# 

#include  $(SMART_INCLUDE_DIR)/SMART_sources.mk 
#include  $(SMART_INCLUDE_DIR)/SMART_deps.mk 
#include  $(SMART_INCLUDE_DIR)/SMART_rules.mk 

# 

#  first  sort  and  pnine  the  list  of  objects  to  remove  duplicates 

# 

#PRUNED_OBJ S  =  $(sort  $(OBJS)  $(MODS)) 

# 

#  Rule  for  making  the  library 

# 

#$(TARGET):  $(DEPS)  $(PRUNED_OBJS) 

#  @echo ; 

#  $(MAKE_STATIC_LIB)  $@  $(MAKELIB_FLAGS)  $(PRUNED_OBJS) 


B.6.12  SMART  makelibdefs.mk 


################################# 

# 

#  SMART  Makefile 

# 

#  Required:  TARGET  -  the  target  binary  name 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 
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################################## 

# 

#  This  is  the  default  rule  (first  rule  encountered) 

# 

default  all:  $(TARGET) 

# 

#  Locations  used  by  included  makefiles 

# 

OBJ  SDIR  =  objs/$(ARCH) 

DEPSDIR  =  deps/$(ARCH) 

MODSD1R  = 

# 

#  Common  variables,  rules,  libraries,  and  dependancies 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_defs.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_libs.mk 


B.6.13  SMART  makestaticlib.mk 


#!gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  TARGET  -  the  full  target  library  name 

#  OBJS  -  list  of  objects  in  the  library 

#  MODS  -  list  of  modules  used  by  the  library 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 

# 

#  Include  all  dependancies  and  rules  for  the  target 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_sources.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_deps.mk 
include  $(SMART_INCLUDE_DlR)/SMART_rules.mk 
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#  first  sort  and  prune  the  list  of  objects  to  remove  duplicates 

# 

PRUNED  OBJS  =  $(sort  $(OBJS)  $(MODS)) 


#  Rule  for  making  the  library 

# 

$(TARGET):  $(DEPS)  $(PRUNED_OBJS) 

@$(SHELL)  'if  [  !  -d  $(@D)  ];  then\ 
echo  ;  \ 

echo  Creating  object  directory  $(@D) ;  \ 

$(MKD1R)  $(@D) ;  \ 
ff 

@echo  ; 

$(MAKE_STAT1C_LIB)  $@  $(MAKELIB_FLAGS)  $(PRUNED_OBJS) 


B.6.14  SMART_makedynamiclib.mk 


#!gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  TARGET  -  the  full  target  library  name 

#  OBJS  -  list  of  objects  in  the  library 

#  MODS  -  list  of  modules  used  by  the  library 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zarnke,  Micah 

# 

################################## 

# 

#  Include  all  dependancies  and  rules  for  the  target 

# 

include  $(SMART_INCLUDE_DlR)/SMART_sources.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_deps.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_rules.mk 

# 
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#  first  sort  and  prune  the  list  of  objects  to  remove  duplicates 

# 

PRUNEDOBJS  =  $(sort  $(OBJS)  $(MODS)) 


#  Rule  for  making  the  library 

# 

$(TARGET):  $(DEPS)  $(PRUNED_OBJS) 

@$(SHELL)  'if  [  !  -d  $(@D)  ];  then\ 
echo  ;  \ 

echo  Creating  object  directory  $(@D) ;  \ 

$(MKD1R)  $(@D) ;  \ 
ff 

@echo  ; 

$(MAKE_DYNAM1C_L1B)  $(MAKEL1B_FLAGS)  $(PRUNED_OBJS)  -o  $@ 


B.6.15  SMART  makemod.mk 


#!gmake  -j 

################################# 

# 

#  SMART  Makefile 

# 

#  Required:  OBJS  -  list  of  objects  in  the  binary 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

# 

#  Include  all  common  dependancies  and  rules  for  the  target 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_sources.mk 
include  $(SMART_INCLUDE_DlR)/SMART_deps.mk 
include  $(SMART_INCLUDE_DlR)/SMART_rules.mk 

# 

#  sort  and  prune  the  list  of  objects  to  remove  duplicates 

# 

PRUNED  OBJS  =  $(sort  $(OBJS)) 
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# 

#  Rule  for  building  the  object  files  that  make  up  the  module 

# 

$(TARGET):  $(DEPS)  $(PRUNED_OBJS) 


B.6.16  SMART  makemoddefs.mk 


#!gmake 

################################# 

# 

#  Required:  TARGET  -  full  name  of  target  to  build 

# 

#  Copyright  (c)  1999,2000 

# 

#  Krajcarski,  Robert 

#  Zamke,  Micah 

# 

################################## 

# 

#  This  is  the  default  rule  (first  rule  encountered) 

# 

default  all:  $(TARGET) 

# 

#  Locations  used  by  the  included  makefiles 

# 

OBJ  SD1R  =  objs/$(ARCH) 

DEPSD1R  =  deps/$(ARCH) 

MODSD1R  =  objs/$(ARCH) 

# 

#  Common  variables,  rules,  modules,  libraries,  and  dependancies 

# 

include  $(SMART_lNCLUDE_DlR)/SMART_defs.mk 
include  $(SMART_lNCLUDE_DlR)/SMART_libs.mk 
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Annex  C  MatrixX  Notes  -  Sea  King  Simulator 


C.1  MatrixX  Notes  -  Sea  King  Simulator 

The  information  listed  here  is  by  no  means  a  comprehensive  or  exhaustive  list  of  MatrixX 
functions.  The  notes  here  are  designed  to  guide  the  user  through  some  very  basic  functions  of 
MatrixX  and  simple  model  manipulation. 


For  any  information  on  operation  or  user  interface,  please  consult  the  MatrixX  online 
documentation.  However,  it  is  not  recommended  that  an  individual  unfamiliar  with  the  program 
manipulate  modules  for  the  Sea  King  simulator.  The  following  documentation  should  be 
referenced  for  future  support  of  MatrixX  -  Sea  King  Simulator  software: 


♦  MatrixX  Online  Documentation  CD 

♦  MatrixX  CD-ROM  Installation  Procedure 

♦  MatrixX  Getting  Started  (Windows)  Manual 

♦  MatrixX  System  Administrator's  Guide  (Windows) 

♦  MatrixX  Autocode  Application  Notes. 

C.2  MatrixX  Getting  Started 

MatrixX  consists  of  a  CD-ROM  disk  for  installation  and  another  for  online  documentation. 
Installation  details  can  be  found  with  the  software.  DRDC  Toronto  has  run  MatrixX  on  a 
Windows  NT  SGI  workstation.  To  start  the  program,  click  the  “Xmath”  icon  under  the  Start 
menu. 


MatrixX  has  three  working  environments  for  model  manipulation.  Each  environment  is  specially 
structured  to  allow  for  the  type  of  model  manipulation  desired.  The  first  environment  that  the  user 
will  encounter  is  called  “Xmath”.  This  environment  is  a  command  line  type  of  user  interface.  It 
allows  the  user  to  probe  variable  values  and  complete  mathematical  calculations.  All  simulation 
functions  can  be  accessed  in  this  environment  and  run  in  a  manual  mode  where  the  user  can 
specify  options  at  the  command  line. 
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C.3  Change  in  a  Variable 


Under  the  “Xmath”  environment,  simulation  variables  can  also  be  accessed.  Under  the  current 
system,  all  helicopter  physical,  integrator,  aerodynamic,  engine,  and  atmospheric  data  are 
contained  here.  As  this  is  a  critical  database,  the  following  steps  may  be  taken  to  modify  these 
variables. 


1.  Drop  down  the  “window”  heading  at  the  top  of  the  “Xmath”  environment  and  choose 
“variables”. 

2.  All  variables  used  in  the  current  system  will  be  displayed  within  this  window,  which  is  called 
the  “variable  manager”.  Variables  can  be  grouped  in  partitions  that  allow  for  separate 
identification  in  modules.  To  look  at  variables  located  in  other  partitions,  drop  and  choose  a 
partition  at  the  bottom  of  the  “variable  manager”  window. 

3.  To  modify  a  variable  one  may  choose  to  use  the  buttons  within  the  variable  manager  but 
caution  must  be  used  here.  Only  scalar  variables  can  be  modified  under  the  variable  manager. 

4.  To  modify  any  other  variable,  type  the  variable  name  and  its  value  in  the  command  window 
of  MatrixX.  For  syntax,  see  online  Xmath  documentation. 

Example:  partitionl  .variable  1 =[  1 ,0;0, 1  ]; 


This  will  produce  a  variable  called  “variable  1”  within  the  partition  called  “partitionl”  that  is  the 
identity  matrix. 

C.4  Systembuild 

The  other  environments  contained  within  MatrixX  are  called  the  “Systembuild  Catalog  Browser” 
and  the  “Systembuild  Simulation”  window. 


To  get  to  the  catalogue  browser,  the  user  must  click  on  the  heading  “window”  in  the  Xmath 
environment.  Once  there,  the  user  must  select  the  “Systembuild”  option  on  the  pull  down  menu. 
The  Systembuild  catalogue  browser  window  will  now  appear.  This  environment  is  very  similar  to 
the  standard  Microsoft  Windows  explorer  and  it  allows  the  user  to  manipulate  all  of  the  blocks 
simultaneously.  It  also  gives  all  of  the  block  specific  information  in  a  concise  display  for  the 
entire  simulation.  Block  type,  ID,  sample  period,  inputs,  outputs  and  name  are  all  displayed  in 
this  environment.  The  user  can  also  manipulate  any  of  these  properties  within  the  catalogue 
browser.  The  browser  also  holds  the  simulation  and  autocode  functions  within  a  windows  type 
environment.  Here,  instead  of  using  the  command  line  within  Xmath  to  perform  functions,  they 
are  presented  in  button  format  and  automated. 
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The  Systembuild  environment  can  be  accessed  by  double-clicking  on  any  module  contained 
within  the  Systembuild  catalogue  browser.  A  new  window  will  appear  that  contains  the  module 
that  the  user  has  selected.  This  environment  is  where  the  simulation  and  all  of  the  associated 
blocks  and  their  connections  are  contained.  It  gives  a  graphical  overview  of  the  system  at  any 
level  of  the  simulation.  To  view  a  higher  level,  the  user  can  go  to  the  catalogue  browser  and 
double-click  on  a  higher-level  module  or  use  the  up  folder  icon  in  the  Systembuild  simulator 
window. 


C.5  Save  a  Change 

There  are  many  ways  to  manipulate  data  and  modules  in  MatrixX.  The  simplest  way  to  save  all 
changes  for  a  particular  session  is  to  go  to  the  Xmath  environment  and  to  the  “file”  heading  and 
click  on  “save”  from  the  pull  down  menu.  This  saves  the  entire  model  in  a  file  of  type  .XMD.  All 
data  and  model  changes  will  be  represented  here.  For  detailed  saving  procedures  involving  only 
Xmath  data,  partial  models,  etc.,  consult  the  online  documentation  for  MatrixX. 


C.6  Autocode 

To  AutoCode  a  model,  the  user  must  first  highlight  that  model  in  the  “catalog  browser”  window. 
Once  highlighted  the  user  may  choose  “tools”  from  the  pull  down  menu  and  select  “AutoCode”. 
Then  the  user  must  select  a  file  name  for  the  .c  file. 


For  all  the  Autocodes  performed  by  DRDC  Toronto,  some  advanced  properties  for  AutoCode 
were  used.  The  template  file  SeaKing.tpl  was  used.  Under  the  “Optimization”  heading  “Merge 
1N1T  Sections”,  “No  UY  Structures”,  and  Vectorization  of  “Labels”  were  used.  A  loop  threshold 
of  2  and  array  threshold  of  2  were  also  selected  for  the  vectorization  option.  Once  all  these 
parameters  have  been  selected,  the  user  may  click  OK  to  start  the  AutoCode  process.  A  *.c  and 
*.h  file  should  be  created  according  to  the  name  that  the  user  has  selected. 


C.7  Transfer  AutoCode  to  the  Sea  King  Development 
Directory 

To  transfer  the  code  to  the  Sea  King  Simulator  development  directory  you  are  using,  place  the 
code  in  the  smart/src/Dynamics/FIelo/MatrixX  directory.  In  the  current  scheme  the  code  must  be 
called  SeaKingAutoCode.h  and  SeaKingAutoCode.c  to  work.  Once  the  code  has  been  copied 
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over  correctly,  the  directory  can  be  built  by  typing,  “make”.  This  step  will  compile  the  source 
code  and  create  a  library  libSMARTMatrixX.a. 


C.8  Structure  of  the  MatrixX  Dynamics  Code  Model 

The  generated  AutoCode  defines  many  global  variables  and  several  global  functions  that  do  all 
the  calculations  for  the  dynamics  model.  One  super  function,  subsys_l(),  is  responsible  for 
calling  all  the  functions  and  handling  all  the  variables  in  the  correct  manner.  This  function  takes 
in  an  input  structure  that  has  all  the  positions  of  the  flight  controls  as  well  as  several  flags  that  tell 
the  state  of  the  helicopter  and  an  output  structure  that  will  contain  the  updated  instrument 
readings. 


A  wrapper/ driver  program  is  used  to  call  the  subsys_l()  function  with  the  appropriate  input  and  to 
relay  the  resulting  helicopter  behaviour  to  the  simulator.  This  is  all  contained  in  the 
SeaKingDriver  class. 


C.9  Troubleshooting  Process 

1.  If  the  AutoCode  did  not  generate  properly  with  no  errors  then  the  C  code  will  not  compile 
properly. 

2.  If  the  MatrixX  model  is  changed  even  a  little  bit,  the  layout  of  the  generated  C  code  will  be 
drastically  affected.  The  driver  program  is  written  so  as  to  use  a  specific/perfect  MatrixX 
model.  This  perfect  C  code  model  is  defined  by  these  characteristics: 

♦  No  dezero  structure  in  the  input  structure 

♦  There  is  a  Sys  Extin  structure,  and  a  subsy  l  out  structure.  If  you  have  a 
SysExtin  structure  and  a  Subsys  Extout  structure,  as  well  as  a  subsys  l  in 
structure,  you  will  need  to  either  change  the  MatrixX  model  to  eliminate  what  is 
causing  the  multiple  structures  or  change  the  driver  so  that  the  input  data  is  being  put 
to  the  subsys  l  in  structure  and  that  structure  is  being  passed  to  the  subsys_l() 
function. 

3.  If  the  AutoCode  still  does  not  compile,  then  it  is  required  to  AutoCode  the  MatrixX  model 
using  the  standalone  template,  c_sim3.tpl,  provided  by  UT1AS.  This  template  will  create  a  C 
program  that  will  take  in  a  MatrixX  input  file,  generated  in  MatrixX  that  contains  the  inputs 
to  the  model  over  a  specific  time  period  and  generate  an  output  file  that  has  all  the  data  from 
the  outputs  for  each  cycle  during  the  run.  Compile  this  program,  linking  in  all  the  sa_*.*  files 
that  are  needed.  If  this  AutoCode  will  not  compile  then  there  is  a  problem  in  the  MatrixX 
AutoCode  procedure.  This  program  should  also  give  the  same  basic  behaviour  as  the  MatrixX 
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model  simulated.  However,  Slightly  different  results  may  be  produced  because  of  the 
random  number  generator  used  in  calculating  the  wind  effects  of  turbulence. 

4.  If  the  standalone  program  compiles  and  runs,  then  look  at  the  driver  program  and  what  it  is 
doing.  The  C  code  generated  by  the  Sea  King  template  is  basically  the  same  code  generated 
by  the  standalone  program  except  the  scheduler  and  main  functions  are  removed.  The  driver 
and  the  simulator  take  the  place  of  these. 

5.  Even  if  the  AutoCode  would  compile  eventually,  the  helicopter  may  behave  strangely.  This 
is  due  to  the  fact  that  the  process  is  not  very  stable  and  any  number  of  problems  big  or  small 
will  cause  the  helicopter  to  behave  improperly.  Unfortunately,  only  spending  a  lot  time 
debugging  the  simulator  will  help  you  figure  out  what  is  going  on.  The  following  tips  will 
help  debug  the  problems: 

♦  Startup:  the  trimming  process  used  to  stabilize  the  helicopter  is  to  be  used  on  for 
startup  during  flight.  Here  the  helicopter  should  be  very  well  behaved,  and  should 
stay  at  the  same  height,  speed  and  such.  Starting  on  the  ground  is  not  supported  by 
UT1AS,  so  the  helicopter  is  trimmed  just  above  the  deck  and  is  then  slowly  lowered 
to  the  deck.  This  is  a  troublesome  way  of  doing  it  but  after  a  lot  of  time  we  found  a 
way  of  making  it  work.  However,  any  changes  to  the  model  or  driver  may  not  make 
starting  on  the  deck  as  good  as  it  was. 

♦  Flight:  to  debug  problems  during  flight,  make  sure  that  all  the  correct  inputs  are 
being  sent  and  that  all  the  correct  flags  are  on.  Then  look  at  the  forces  on  the 
helicopter.  The  forces  come  from  several  different  areas,  the  tail,  rotor,  landing 
gear,  and  haul-down  system.  If  any  of  these  forces  behave  strangely  or  are  too  large 
then  isolate  that  subsystem  and  continue  backtracking  to  determine  what  is  causing 
that  force  to  behave  strangely. 
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Annex  D  Modifications  of  Simulator  Visual  Models 


D.1  Introduction 

There  are  two  main  visual  models  in  the  simulator,  the  CPF  and  the  Sea  King  helicopter.  Both  of 
these  three-dimensional  objects  were  modeled  using  MultiGen  Creator,  which  has  the  file 
extension  classfification  .fit.  MultiGen  Creator  is  a  modelling  tool  that  produces  realistic  three- 
dimensional  models  for  use  in  real-time  applications.  One  of  the  reasons  why  this  modelling 
software  package  is  the  most  used  presently  in  the  industry  of  real-time  modelling  is  the 
integrated  set  of  powerful  tools  it  offers  for  building  hierarchical  visual  databases.  The  main 
distinction  between  this  modelling  design  software  package  and  most  others  is  its  ability  to  create 
a  database  to  control  and  maintain  objects  during  real-time  simulations.  The  database  design 
aspect  of  the  models  created  in  Creator  inherits  theories  and  concepts  from  conventional  database 
design  methodologies.  Using  this  convention,  dynamic  visual  simulations  can  be  created 
effectively  while  still  maintaining  the  characteristic  of  manipulating  data  in  an  optimized  manner. 


To  fully  understand  how  to  maintain  and  upgrade  visual  models  for  real-time  simulation,  a  clear 
understanding  of  the  goals  of  real-time  applications  must  be  discussed.  The  following  is  a  list  of  a 
few  of  the  most  fundamental  goals  of  real-time  applications. 


1.  The  emphasis  is  on  immersive  interaction  between  active  audiences  (i.e.  Pilot,  LSO,  Instructor, 
etc.)  and  responsive  simulation. 

2.  Real-world  dimensions,  rules,  and  constraints  are  important  to  the  goals  of  the  simulation  (e.g., 
the  locations  of  certain  pilot  controls,  maximum  and  minimum  angle  of  rotation  for  those 
controls). 

3.  Frames  must  be  fully  rendered  and  displayed  at  30  to  60  frames  per  second.  In  the  Simulator, 
the  target  frame  rate  is  set  at  60  frames  per  second. 

4.  Efficient  polygonal  models  contain  only  the  necessary  polygons  to  achieve  the  desired  effect. 
The  desired  effect  can  entitle  showing  only  correct  visuals  to  corresponding  active  audiences. 

5.  Data  structures  are  hierarchically  optimised  for  program  traversal  and  1G  state  control.  Data 
also  contains  model  controls,  real-world  constraints,  and  geometry  optimizations. 


Using  the  above  rules  as  guidelines  for  maintaining  and  upgrading  models  for  real-time  will 
facilitate  the  progression  of  making  changes  in  the  simulator  visual  models  for  the  future. 
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D.2  Simulator  Database  Design  and  Concepts 


Most  of  the  upgrading  and  maintenance  of  a  model  created  in  MultiGen  Creator  is  done  in  the 
hierarchical  design  of  the  database.  The  conventional  database  design  of  a  3D  model  in  MultiGen 
Creator  integrates  the  concepts  of  data  tree  structures  from  fundamental  computer  algorithmic 
theories.  The  result  of  a  database  created  in  MultiGen  Creator  is  a  directed  acyclic  graph  of 
nodes.  An  initial  database  of  a  three-dimensional  model  starts  with  a  root  parent  node  called  db. 
This  node  simply  represents  the  entire  database  and  any  information  about  the  database/model  as 
a  whole.  In  the  hierarchical  view  of  MultiGen  Creator,  double-clicking  on  the  db  parent  node  of  a 
database  will  trigger  a  window  to  pop  up  with  the  attributes  of  that  node.  For  a  database  node  db, 
attributes  include  the  format  origin,  revision  date,  format  version,  database  units,  and  more. 


The  Sea  King  helicopter  database  hierarchy  is  shown  in  Figure  D-l.  Note  that  the  database 
(/savdb/models/Seaking/Seaking_MARCFH5.flt)  is  not  fully  expanded  and  only  shows  the  major 
parent  nodes  that  control  the  most  essential  parts  of  the  database. 
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Heli cop 


Figure  D-  1:  Hierarchical  View  of  Sea  King  Helicopter  Database 


DRDC  Toronto  TM  2011-050 


81 


In  the  Sea  King  database  view  shown  in  the  previous  figure,  the  main  parent  node  of  the  database 
is  the  db  node.  The  child  of  this  node  is  a  node  that  represents  the  entire  helicopter  model.  When 
changes  are  made  to  this  node,  the  entire  sub-tree  inherits  the  modifications.  For  instance,  when 
applying  a  transformation  to  the  helicopter’s  position,  the  helicopter  node  needs  to  be  selected  in 
order  to  apply  the  transformation  matrix.  This  transformation  to  the  helicopter  node  will  be  innate 
in  all  the  children  of  the  node,  thereby  transforming  all  geometry  by  the  same  transformation 
matrix. 


The  child  node  of  the  helicopter  node  is  called  a  degree  of  freedom  node  (the  white  coloured  node 
labelled  Heli  DC  (DOF)).  This  is  a  special  node  that  is  created  in  order  to  allow  real-time 
graphics-rendering  tools,  such  as  OpenGL  performer  to  set  the  co-ordinates  of  objects  during  the 
simulation.  The  degree  of  freedom  node  is  a  node  that  controls  the  movement  of  all  children 
objects.  Because  the  transformation  of  objects  is  done  during  a  real-time  simulation,  the  DOF 
node  is  controlled  in  real-time  by  OpenGL  performer’s  real-time  programming  interface.  For 
example,  if  the  helicopter  is  moving  in  three-space,  the  OpenGL  performer  class  representing  the 
Heli  (DOF)  node  will  need  to  know  the  new  three-dimensional  co-ordinates  of  the  helicopter  in 
order  to  apply  the  transformation  to  the  helicopter. 


Another  imperative  node  is  the  “switch”  node  (three  purple  nodes  in  Figure  D-l).  There  are  three 
switch  nodes  that  are  children  of  the  Helicopter  (DOF)  node,  (InsideSwitch,  Outline, 
Low  Detail).  The  main  purpose  of  a  switch  node  is  to  allow  a  switch  between  groups  that  are 
children  of  the  switch  node.  For  example,  the  first  switch  node  of  the  helicopter  degree  of 
freedom  node  is  the  Inside  Switch.  This  switch  node  has  two  children  group  nodes,  Inside  and 
Outside.  The  Inside  group  node  is  parent  to  all  the  geometry  of  the  helicopter’s  inside  and  the 
outside  group  node  is  the  parent  node  of  all  the  geometry  of  the  helicopter  from  the  outside  point- 
of-view.  The  Inside  Switch  node  allows  the  switching  between  the  inside  group  node  and  the 
outside  group  node.  For  instance,  the  pilot’s  point-of-view  within  the  inside  group  is  the  inside 
view  of  the  helicopter.  This  means  that  the  Inside  Switch  node  will  have  a  value  set  to  0;  only  the 
inside  geometry  of  the  helicopter  will  need  to  be  drawn.  On  the  contrary,  the  outside  view  of  the 
helicopter  will  be  needed  for  either  the  Instructor  GUI  or  the  LSO  simulator.  Both  of  these  views 
will  only  require  seeing  the  outside  of  the  helicopter.  The  details  of  the  inside  of  the  helicopter 
can  and  should  be  hidden  from  any  point-of-view  of  the  helicopter  from  the  outside.  If  the  graphic 
view  of  the  Instructor  GUI  is  needed  from  the  model,  then  the  switch  node  that  controls  whether 
the  inside  or  the  outside  is  to  be  rendered  should  be  set  to  1 ,  representing  the  outside.  Switch 
nodes  in  the  helicopter  database  can  also  control  light  switches,  2  states  (on,  off),  daytime  or 
night-time  control  panel,  probe  up  or  probe  down,  and  much  more.  In  setting  the  attributes  of  a 
switch  node,  the  number  of  switch  states  can  be  set  as  a  mask.  However,  during  a  real-time 
simulation,  the  switch  node  states  are  controlled  by  OpenGL  performer’s  programming  interface. 


In  addition  to  the  “special”  nodes  mentioned  above,  there  is  another  “special”  node  called  the 
Level  of  Detail  (LOD)  node.  The  LOD  node  represents  the  switching  between  a  set  of  models  that 
represent  the  same  obj  ect  with  varying  degrees  of  complexity.  The  real-time  system  selects  one  of 


82 


DRDC  Toronto  TM  2011-050 


the  LODs  to  display,  depending  on  the  distance  from  the  eye  point  to  the  LOD  and  on  the  number 
of  polygons  the  real-time  system  can  process.  For  example,  if  a  light  point  needs  to  be  seen  from 
a  long  distance  away  from  the  eye-point,  then  the  LOD  node  will  display  the  least  complex  light 
point  object  since  the  details  will  not  benefit  any  visuals  because  the  object  is  far-off.  This 
predominately  helps  save  polygons  by  displaying  a  lower  complexity  version  of  an  object.  As  the 
eye -point  from  the  pilot  gets  closer  to  the  object  that  is  a  child  of  the  LOD  node,  the  LOD  will 
make  a  transition  to  a  higher  complexity  version  of  the  object  being  viewed.  The  transition  is 
done  over  a  range  of  a  distance. 


There  are  several  other  special  nodes  in  a  MultiGen  Creator  database,  but  the  few  nodes 
mentioned  above  are  in  all  probability  the  most  imperative  nodes.  When  making  changes  to  a 
visual  model,  there  are  a  variety  of  tools  that  MultiGen  Creator  can  provide.  There  are  rules  and 
tips  in  making  changes  to  the  hierarchy  and  the  graphics  view  of  the  model.  This  document  will 
not  go  in  depth  with  the  explanation  of  the  tools  available.  The  explanation  of  the  tools  can  be 
found  in  the  MultiGen  Creator  manual.  One  can  also  do  a  search  on  the  Creator  help  search  menu 
as  shown  in  Figure  D-2.  This  menu  includes  most  of  the  topics  and  tools  and  how  to  use  them. 
The  Help  menu  will  explain  in  detail  with  example  how  to  use  virtually  all  the  tools  that 
MultiGen  Creator  has  to  offer.  However,  it  will  not  explain  in  depth,  the  effects  of  your 
modification  to  the  real-time  graphics-rendering  interface. 
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Figure  D-  2:  Creator  Help  Index  Menu 

The  menu  will  have  information  on  virtually  every  particular  creator  topic  from  how  to  change  a 
node  name  to  adding  a  state  to  a  switch  node.  This  help  guide  will  also  include  examples  that  will 
guide  the  user  through  the  steps  needed  to  create  an  optimised  MultiGen  Creator  database.  In 
addition,  the  following  DRDC  Toronto’s  documents  can  be  referenced: 


1 .  Introduction  to  MultiGen  Creator  [Reference  c] 

2.  MultiGen  Creator  Modelling  Techniques  and  Performance  Optimization  [Reference  d] 
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D.3  Modification 


During  the  development  stages  of  the  simulator,  there  were  various  diminutive  changes  made  to 
the  hierarchy  of  the  visual  model  databases.  The  process  of  making  modification  became  an 
iterative  step  into  creating  efficient  real-time  models.  Once  changes  were  made  in  the  hierarchy,  a 
verification  step  was  taken  to  make  sure  the  OpenGL  performer  interface  matched  the  changes 
made.  Because  the  OpenGL  performer  interface  is  done  using  C++  code,  the  entire  software  for 
the  simulator  had  to  be  recompiled  and  run  again  to  view  the  changes. 


The  main  problem  in  making  modification  to  the  database  occurs  when  there  is  a  change  made 
involving  the  OpenGL  interface  and  the  creator  database.  The  main  thing  to  remember  about  the 
OpenGL  performer  interface  is  that  it  is  in  charge  of  mainly  handling  “special”  database  nodes.  It 
needs  to  know  the  names  of  the  main  database  node,  degree  of  freedom  nodes,  switch  nodes,  level 
of  detail  nodes  and  any  other  special  nodes  that  allow  real-time  updating.  In  the  simulator,  the  Sea 
King  helicopter  model  has  the  performer  controls  in  this  configuration  file 
(~local/rhs/hdls/config/seaking_flt_model.sdb)  as  shown  in  Figure  D-3. 
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Figure  D-  3  OpenGL  Configuration  File  for  the  Sea  King  Database 


For  maintenance  purposes,  this  is  the  only  file  that  needs  to  be  changed  if  a  node  name  is  changed 
in  the  database  hierarchy  of  the  models.  The  key  thing  to  remember  here  is  that  Performer  only 
needs  to  know  the  name  of  the  node,  if  code  is  written  for  it,  to  control  objects  and  set  constraints. 
Most  of  the  basic  changes  made  in  the  database  do  not  affect  the  OpenGL  performer  interface 
unless  modifications  change,  add  or  remove  any  of  the  “special”  nodes  in  the  database.  For 
example,  if  the  name  of  the  helicopter  degree  of  freedom  node  is  changed  from  Heli  DC(DOF)  to 
Seaking  Dof  then  the  name  change  needs  to  be  made  in  the  database  hierarchy  and  also  the 
performer  configuration  file  that  refers  to  the  helicopter’s  degree  of  freedom  node.  Flowever,  if  a 
more  serious  change  is  made,  such  as  adding  a  new  node  or  making  changes  to  the  switch  states 
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of  a  switch  node,  then  the  new  node  or  changes  have  to  be  registered  in  the  C++  OpenGL 
performer  interface.  This  means  that  the  C++  code  needs  to  be  written  or  modified. 


During  the  simulator  development  stages,  generic  base  classes  were  written  to  support  virtually 
all  the  “special”  nodes  that  MultiGen  Creator  offers.  Then  for  each  individual  object,  code  was 
written  to  support  the  specific  functionality  of  the  object.  The  following  is  a  basic  example  of 
how  to  add  a  collective  to  a  model  and  then  set  up  the  performer  interface  to  control  the 
movement  of  it.  Using  this  brief  procedure  as  a  guideline,  future  modification  can  transition 
smoothly  in  the  simulation. 


The  initial  step  is  creating  the  actual  three-dimensional  model  by  using  MultiGen  Creator’s 
modelling  utilities.  Conversely,  if  certain  geometries  need  to  be  accurate  to  real-world  objects,  a 
laser  scanner  can  be  used  to  generate  models  that  can  be  imported  into  MultiGen  Creator.  In  the 
case  of  the  Sea  King  simulator,  a  laser  scanner  was  used  to  capture  the  three-dimensional  object 
to  within  2  mm  accuracy.  Figure  D-4  shows  the  changes  that  need  to  be  made  to  the  creator 
hierarchy  in  order  to  insert  a  collective  into  the  database  (Seaking_Version_2.6.flt). 


Figure  D-  4  Inserting  Collective  Geometry  in  the  Database 


To  create  this  sub-tree,  select  the  parent  node  of  the  new  geometry  that  is  going  to  be  added.  In 
the  above  figure,  this  refers  to  the  pilot  group  node.  To  create  a  child  for  this  node,  simply  click 
on  the  node  and  then  click  on  the  icon  labelled  parent  at  the  bottom  left  of  the  screen.  This  will 
assign  the  node  as  the  parent  node  of  the  database.  Now  that  the  node  is  selected,  any  new  group, 
object,  special  node  created  will  be  a  child  of  the  selected  parent  node. 
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The  collective  will  definitely  need  to  have  the  desired  characteristic  of  being  able  to  rotate  about 
the  bottom  edge.  To  allow  the  collective  geometry  to  be  controlled  in  real-time,  a  degree  of 
freedom  node  needs  to  be  created  as  the  parent  node  of  the  geometry.  Once  the  degree  of  freedom 
node  is  created,  select  this  degree  of  freedom  node  as  the  parent  node.  Subsequently  create  an 
object  node  as  the  child  of  the  degree  of  freedom  node.  Selecting  the  degree  of  freedom  as  the 
parent  node  and  then  selecting  create  group  node  from  the  menu  option  can  accomplish  this.  After 
this  is  completed,  select  the  object  node  created  as  the  parent  node  and  the  geometries  of  the 
collective  can  be  modelled  as  children  by  using  the  creator  modelling  utilities.  When  creating 
nodes  in  MultiGen  Creator,  double-clicking  the  node  in  the  hierarchy  view  will  allow  attributes, 
such  as  switch  state  mask  for  switch  nodes,  bounding  area  for  groups,  light  point  controls,  light 
source  attributes,  to  be  set.  Most  of  the  attributes  set  in  MultiGen  Creator  will  transfer  over  to 
OpenGL  performer  as  shown  in  Figure  D-5.  When  OpenGL  performer  registers  the  database,  it 
uses  a  loader  to  detect  the  nodes  and  all  the  attributes  associated  with  it. 


The  database  is  transferred  into  an  internal  data  representation  that  allows  the  data  to  be 
manipulated  using  a  C++  code  interface. 
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Figure  D-  5  Loading  MultiGen  .fit  into  OpenGL  Performer 
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The  subsequent  action  is  writing  code  to  control  the  collective.  Because  this  document  explains 
how  to  maintain  and  add  to  already  existing  code,  the  procedures  will  be  basic  and  maybe  even 
partial.  Most  of  the  supporting  code  is  already  written  for  the  control  of  objects  in  the  simulator. 
Figure  D-6  shows  the  code  written  for  the  collectives  class,  both  the  pilot  and  the  co-pilot.  This 
figure  shows  the  Collective.hpp  file,  which  subsequently  shows  the  collectives’  controlling 
functions. 


ffifndef  COLLECT I VE_HPP 
#define  COLLECT I VE_HPP 

namespace  SMART ■[ 
class  DCSHandle; 

template  <class  T,  int  S>  class  Coord; 
typedef  Coord<double,3>  .Coord3d; 

//  SMART 

}; 

namespace  SAVDB  { 

class  Collective 

{ 

public: 

enum  Col lectiveType  {PI LOT, COPILOT}; 

Collective(  SMART: : DCSHandle*  pHandle,  Col lectiveType  CollectiveObject); 
virtual  ~Col 1 ecti ve( ) ; 

void  setCol 1 ect i ve(  const  double  Collective)  ; 
void  setType( Col lectiveType  col lectiveType); 

protected: 

SMART: : DCSHandle*  m_pSwitch; 
private: 

Collective(  const  Collective  &  rhs  ); 

Col lectiveType  m_eCol lectiveType; 

1 » 


*  Inline  methods 

*  Description: 

*  Place  all  inline  methods  below  here 
};  //  SAVDB 


Figure  D-  6Collective  Header  File 

Instantiating  this  class  as  an  object  will  require  a  “pHandle”  and  a  collective  type.  The  “pHandle” 
represents  the  degree  of  freedom  node  that  controls  the  collective’s  rotation  and  the  type 
establishes  whether  it  is  a  pilot  collective  or  a  “slaved”  co-pilot  collective.  After  this  object 
establishes  these  attributes,  then  it  is  just  a  matter  of  having  functions  to  move  the  collective 
every  time  new  values  are  updated  from  the  “cereal  box”  hardware  interface.  Most  of  the 
rendering  classes  are  associated  with  manipulating  co-ordinates  of  three-dimensional  objects  in 
real-time.  However,  there  are  additional  real-time  rendering  functions  that  control  other  “special” 
nodes.  Some  of  these  “special”  nodes  were  discussed  early  in  this  document. 
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Switch  nodes  for  instance  are  fairly  easy  to  control,  it  is  simply  a  function  that  selects  which  child 
of  the  switch  node  will  be  displayed  in  each  frame  of  the  simulation. 


There  are  many  other  tools  and  functions  that  performer  provides  for  rendering  graphics  and 
controlling  objects  during  a  simulation.  Performer  can  control  dynamic  co-ordinates  nodes,  static 
co-ordinate  nodes,  switch  nodes,  level  of  detail  nodes,  light  point  nodes,  light  source  nodes, 
billboard  nodes  and  many  others.  For  more  information  about  OpenGL  performer  and  its 
functionalities,  refer  to  the  OpenGL  performer  programmer’s  guide. 

D.4  Summary 

When  maintaining  visual  models  for  simulation,  there  are  several  rules  and  factors  that  should  be 
considered.  Rules  such  as  keeping  a  frame  rate  at  60  frames  per  cycle,  culling  unnecessary 
groups,  optimizing  hierarchy  structure  are  just  some  of  the  rules  that  can  help  alleviate  the 
modifications  process.  Modifications  to  a  MultiGen  Creator  database  can  be  made  as  long  as 
OpenGL  Performer  can  “register”  the  changes.  This  means  that  the  hierarchy  can  be  restructured 
without  changing  the  performer  interface  as  long  as  the  changes  made  to  the  “special”  node(s)  in 
the  database  are  registered  within  the  performer  interface.  If  a  drastic  modification  or  update  is 
made  such  as  inserting  a  new  helicopter,  then  the  pre-existing  design  methodologies  of  the  Sea 
King  Simulator  can  be  inherited  in  the  new  database  design.  If  the  new  helicopter  has  the  same 
type  of  characteristics  as  the  Sea  King  helicopter,  such  as  having  a  collective,  cyclic  and  pedals, 
then  the  only  modification  that  needs  to  be  made  is  generating  the  three-dimensional  model.  The 
new  constraints  for  each  control  can  then  be  inserted  in  the  OpenGL  Performer  interface  for  each 
object.  For  example,  if  a  new  gauge  for  a  Jet  Ranger  needs  to  be  inserted,  then  code  needs  to  be 
written  for  the  control  of  this  gauge.  Then  again,  this  is  as  simple  as  using  the  Sea  King  gauges 
from  the  simulator  as  examples  and  writing  a  class  that  inherits  all  the  attributes  of  a  generic 
gauge. 


Using  the  suggestions  and  rules  stated  in  this  document  will  help  smooth  the  process  of 
maintaining  three-dimensional  visual  models  for  simulation.  If  the  proper  design  steps  are  taken 
before  the  development  stages  of  creating  a  visual  database,  then  the  modifications  procedure 
should  not  be  difficult.  The  key  thing  to  remember  is  the  organisation  of  nodes  in  the  database 
can  definitely  affect  the  runtime  system  during  the  traversal  of  the  hierarchy  during  the  culling 
and  drawing  stages  of  the  rendering  process. 
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